On Tue, 27 Aug 2013, Mark Andrews wrote: > In message <[email protected]>, > "C. M. Heard" writes: > > Here are some other suggestions: > > > > - Make this a destination option that appears before the > > fragmentation header, not a hop-by-hop option, as discussed in a > > previous e-mail in this thread. > > It is quite possible to develop asics which understand this option > the same way as there are asics which process tcp and udp headers.
could be developed != exists in current core routers Existing core routers are likely to punt hop-by-hop options to a slow path. But they aren't the cause of the fragment dropping problems. So we should seek a solution that does not require updating them. I don't see why a destination option (apearing BEFORE the fragment header) would not work just as well as a hop-by-hop option while being immune from this particular problem. > > - This option MUST NOT appear in an initial fragment (or in an > > unfragmented fatagram). That avoids the possibiity that a > > middlebox will interpret a datagram differently from an end system > > (or another middlebox). > > This is a non starter. Whatever change we make needs to be visible in > all fragment. Firewalls need to be able to identify if the packet is > following old fragmentation rules or new fragmentation rules so it can > decide if it is applying old policy or new policy. I don't see that. The initial fragment, without the option, already has the upper-layer information that a firewall needs in order to apply a filtering policy (assuming of course that it complies with draft-ietf-6man-oversized-header-chain). Non-initial fragments get dropped because that information is missing. The option provides the missing information. Firewalls that discard non-initial fragments will need to be updated to use the option. Firewalls that unconditionally drop anything with a fragment header will need also to be updated not to drop initial fragments (as long as those fragments contain a complete upper-layer header, per draft-ietf-6man-oversized-header-chain). Either way, an update to the firewall is required. The downside of putting the option into initial fragments is what can happen if there is a mismatch between the contents of the option and the actual upper-layer header if both are present. If for ease of implementation the firewall uses the option but not the upper-layer header (so that all fragments are treated the same), what it lets through may be interpreted differently by an end system than the firewall expected (this is particularly true for old end system implemantations that have not been updated to recognize the option) -- in other words, there is a possibility of evading the firewall's policy. This possibility is completely elminated by eliminating the duplicate information, i.e., by leaving the option out of initial fragments (and unfragmented datagrams). It is true that an initial fragment generated by an old implementation and generated one by a new implementation cannot be distinguished under my proposal. The worst that happens is that the initial fragment generated by an old implementation gets through, but succeeding ones do not. In that case some resources are consumed on the destination host, but the datagram does not get through (as intended by the firewall). Indeed, in looking at http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf which was a primary reference for draft-taylor-v6ops-fragdrop, it seems that is generally (or often) what happens today. //cmh -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
