Hi Mike,

> -----Original Message-----
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] 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
fred.l.temp...@boeing.com

> Mike Heard
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to