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. 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. //cmh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
