In message <2134f8430051b64f815c691a62d983180df...@xch-blv-504.nw.nos.boeing.co m>, "Templin, Fred L" writes: > Hi Mike, > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf Of > > C. M. Heard > > Sent: Saturday, August 03, 2013 9:21 AM > > To: IPv6 > > Subject: Re: UDP+Fragmentation > > > > On Sat, 3 Aug 2013, Brian E Carpenter wrote: > > > On 02/08/2013 18:12, Mark ZZZ Smith wrote: > > > > [ Mark ZZZ Smith wrote ] > > ... > > > > > [ C. M. Heard wrote ] > > ... > > > > > > - generic transport encapsulation within UDP (suggested to me > > > > > > off-list by Mark Smith, based on a draft by Stuart Cheshire > > > > > > et. al.). > > ... > > > May I make a plea for any such proposal to be carefully evaluated > > against > > > common practices in stateful firewalls and load balancers. I'm rather > > concerned > > > that the problems these middleboxes create with conventional > > fragmentation > > > will soon come back with UDP-encapsulated fragmentation. (There is no > > problem > > > in computer science that can't be made harder by recursion.) > > > > Yes, UDP-encapsulated fragmentation (in its simplest form) has > > exactly the same issue as conventional IP fragmentation -- it hides > > the actual L4 header information in all but the first fragment. > > Operators who filter conventional IP fragments would have exactly > > the same motivation to filter UDP-encapsulated fragments. > > > > On Thu, 1 Aug 2013, Mark ZZZ Smith wrote: > > > (2) fragments can hide transport layer protocol ports, preventing > > > simple ACL filtering etc. > > ... > > > A general solution like SEAL (which I think in the big picture > > > would be better), probably doesn't solve (2) > > > > SEAL transport mode, as currently proposed, addresses the problem by > > including port numbers in all non-initial segments:. See: > > > > https://tools.ietf.org/html/draft-templin-intarea-seal-61#page-32 > > Thanks for pointing this out. Another problem I have heard is that > initial fragments are sometimes so small that the L4 information > does not fit, or that non-initial fragments may sometimes "overlap" > the initial fragment and invalidate any filtering checks that were > applied to the initial fragment. SEAL addresses this by requiring > that the initial fragment be at least 256 bytes in length and that > all fragments except the final one contain an integer multiple of > 256 byte blocks. Overlapping fragments are also explicitly forbidden. > > Thanks - Fred > [email protected] > > > Mike Heard > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > [email protected] > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------
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. Mark -- 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 --------------------------------------------------------------------
