In message <[email protected]>, "C. M. Heard" writes: > On Tue, 6 Aug 2013, Mark Andrews wrote: > > SEAL however doesn't appear to be incrementally deployable. You need > > the destination to be SEAL aware as it is a destination header not a > > destination option. > > Except for the hop-by-hop option proposal in > > http://tools.ietf.org/id/draft-andrews-6man-fragopt > > all of the proposals informally floated so far suffer from that > disadvantage. That includes a new version of UDP with segmentation, > generic transport encapsulation within UDP, and SEAL. > > As mentioned elsewhere, generic transport encapsulation within UDP > does not really address the problem, as it lacks L4 header > information in all fragments except the first (see > http://www.ietf.org/mail-archive/web/ipv6/current/msg18687.html). > > The hop-by-hop option proposal and SEAL suffer from a security hole: > the L4 information is duplicated, and thereby creating a security > hole. An attacker could put one thing in the option or in the SEAL > header (to be interpreted by a middlebox) and another thing in the > actual transport header (to be interpreted by an end system). A new > version of UDP would not have this problem, as the same header would > be interpreted by both the middlebox and the end system.
Actually draft-andrews-6man-fragopt doesn't as the option is in all fragments and policy devices can decide whether to pass mis-matching initial fragments or not. I don't see policy devices passing non-initial fragments where you can't do this check. A filter rule like "pass dstport 80 srcport any" would enforce that destination ports matched but wouldn't care that the source ports didn't. > The hop-by-hop option proposal suffers from another problem. Quoting > from http://tools.ietf.org/id/draft-ietf-6man-ext-transmit-02.txt > Section 2.2: > > It is to be expected that high performance routers will either > ignore it, or assign packets containing it to a slow processing > path. Designers planning to use a Hop-by-Hop option need to be > aware of this likely behaviour. > > The problem in the present case arises if high performance routers > put packets with hop-by-hop options on a slow path. Well properly design your router. It is a design choice to slow path hop-by-hop processing. > //cmh > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
