In message <[email protected]>, Mark Andrews writes:
>
> In message <[email protected].
> 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
s/incrementally/opportunistically/
> 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
> --------------------------------------------------------------------
--
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
--------------------------------------------------------------------
