Re: UDP+Fragmentation (was: "Deprecate")

On 09/24/2013 10:51 PM, C. M. Heard wrote: >> If you care about fragmentation-based attacks, you really don't want to >> use TCP. There are a bunch of attacks that can be (by far) more >> devastating than the fragmentation-based ones (see >>

Re: UDP+Fragmentation (was: "Deprecate")

On Mon, 23 Sep 2013, Fernando Gont wrote: > On 09/23/2013 12:57 AM, C. M. Heard wrote: > > > > There are two issues that Warren's comments brought to the fore: > > > > 1.) One of the reasons why operators block fragments is that if > > fragments are allowed into one's network, it is relative

RE: UDP+Fragmentation (was: "Deprecate")

Hi, I have done some looking around on linux and found two more sources of IPv6 fragmentation. First, unless explicitly told not to, 'ping6' will use IPv6 fragmentation to ensure that ICMPv6 echo request packets larger than the path MTU are delivered to the final destination. The destination then

Re: UDP+Fragmentation (was: "Deprecate")

On 09/23/2013 12:57 AM, C. M. Heard wrote: > > There are two issues that Warren's comments brought to the fore: > > 1.) One of the reasons why operators block fragments is that if > fragments are allowed into one's network, it is relatively easy > for an attacker to make a DOS attack on

Re: UDP+Fragmentation (was: "Deprecate")

In message , "C. M. Heard " writes: > On Mon, 26 Aug 2013, C. M. Heard wrote: > > Upon reflection, I have come to the conclusion that the proposal > > in draft-andrews-6man-fragopt (or a variant thereof) is a much > > better solution to the problems with IPv6 fragmentation than the > > UDP segm

Re: UDP+Fragmentation (was: "Deprecate")

On Mon, 26 Aug 2013, C. M. Heard wrote: > Upon reflection, I have come to the conclusion that the proposal > in draft-andrews-6man-fragopt (or a variant thereof) is a much > better solution to the problems with IPv6 fragmentation than the > UDP segmentation scheme I proposed. > > The huge advan

RE: UDP+Fragmentation (was: "Deprecate")

n...@ietf.org] On Behalf Of > C. M. Heard > Sent: Monday, August 26, 2013 9:38 PM > To: IPv6 > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > Greetings, > > Upon reflection, I have come to the conclusion that the proposal in > draft-andrews-6man-fragop

RE: UDP+Fragmentation (was: "Deprecate")

> > > -Original Message- > > From: Templin, Fred L [mailto:fred.l.temp...@boeing.com] > > Sent: Tuesday, August 06, 2013 6:36 PM > > To: Ronald Bonica; C. M. Heard; IPv6 > > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > > >

RE: UDP+Fragmentation (was: "Deprecate")

On Tue, 6 Aug 2013, Templin, Fred L wrote: > One other thing for now is that Mike's proposal doesn't even > address the attack vector that 'draft-bonica-6man-frag-deprecate' > is concerned about. To address the tiny fragment concern, the > protocol must ensure that tiny fragments cannot ever be cre

RE: UDP+Fragmentation (was: "Deprecate")

From: Templin, Fred L [mailto:fred.l.temp...@boeing.com] > > Sent: Tuesday, August 06, 2013 2:58 PM > > To: Ronald Bonica; C. M. Heard; IPv6 > > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > > > With a protocol as ossified as UDP, I have a hard tim

RE: UDP+Fragmentation (was: "Deprecate")

Hi Ron, Glad to hear you have had a look at SEAL, and see below for a few follow-up comments: > -Original Message- > From: Ronald Bonica [mailto:rbon...@juniper.net] > Sent: Friday, August 09, 2013 4:32 AM > To: Templin, Fred L; C. M. Heard; IPv6 > Subject: RE: UDP+Fra

RE: UDP+Fragmentation (was: "Deprecate")

Fred, Quite to the contrary, I have spent a good deal of time reviewing the SEAL draft. (Although I am now one version behind. The document is now in version 61.) SEAL attempts to solve many problems. These include: - source address authentication - detection of packet duplication and reorderi

RE: UDP+Fragmentation (was: "Deprecate")

Hi Ron, > -Original Message- > From: Ronald Bonica [mailto:rbon...@juniper.net] > Sent: Tuesday, August 06, 2013 6:46 PM > To: Templin, Fred L; C. M. Heard; IPv6 > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > Fred, > > We should probabl

RE: UDP+Fragmentation (was: "Deprecate")

Ron > -Original Message- > From: Templin, Fred L [mailto:fred.l.temp...@boeing.com] > Sent: Tuesday, August 06, 2013 6:36 PM > To: Ronald Bonica; C. M. Heard; IPv6 > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > Ron, > > One other thing for no

RE: UDP+Fragmentation (was: "Deprecate")

s - Fred fred.l.temp...@boeing.com > -Original Message- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > Templin, Fred L > Sent: Tuesday, August 06, 2013 3:07 PM > To: Ronald Bonica; C. M. Heard; IPv6 > Subject: RE: UDP+Fragmentation (was: "Deprecate&

RE: UDP+Fragmentation (was: "Deprecate")

Hi Ron, > -Original Message- > From: Ronald Bonica [mailto:rbon...@juniper.net] > Sent: Tuesday, August 06, 2013 2:54 PM > To: Templin, Fred L; C. M. Heard; IPv6 > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > Fred, > > If that's the

RE: UDP+Fragmentation (was: "Deprecate")

d Bonica; C. M. Heard; IPv6 > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > With a protocol as ossified as UDP, I have a hard time imagining all > middleboxes passing the packets with what they would see as a corrupted > length field. > > Thanks - Fred > fred.l.

RE: UDP+Fragmentation (was: "Deprecate")

Behalf Of > Ronald Bonica > Sent: Tuesday, August 06, 2013 11:49 AM > To: C. M. Heard; IPv6 > Subject: RE: UDP+Fragmentation (was: "Deprecate") > > Mike, > > The proposal sounds elegant. I will try to paraphrase it to make sure > that I understand. > >

RE: UDP+Fragmentation (was: "Deprecate")

; From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > C. M. Heard > Sent: Monday, August 05, 2013 11:53 PM > To: IPv6 > Subject: Re: UDP+Fragmentation (was: "Deprecate") > > On Thu, 1 Aug 2013, C. M. Heard wrote: > > On Thu, 1 Aug 2013, RJ A

Re: UDP+Fragmentation (was: "Deprecate")

On Thu, 1 Aug 2013, C. M. Heard wrote: > On Thu, 1 Aug 2013, RJ Atkinson wrote: > > I agree that C.M. Heard's ideas should be explored > > in more detail by the IETF. The idea was essentially UDP with segmentation fields, which would require a new protocol number. In an offline discussion with M

Re: UDP+Fragmentation (was: "Deprecate")

- Original Message - > From: Mark ZZZ Smith > To: C. M. Heard ; IPv6 > Cc: > Sent: Friday, 2 August 2013 2:55 PM > Subject: Re: UDP+Fragmentation (was: "Deprecate") > > Hi, > > > - Original Message - >> From: C. M. Heard >

Re: UDP+Fragmentation (was: "Deprecate")

Hi, - Original Message - > From: C. M. Heard > To: IPv6 > Cc: > Sent: Friday, 2 August 2013 3:11 AM > Subject: Re: UDP+Fragmentation (was: "Deprecate") > > On Thu, 1 Aug 2013, RJ Atkinson wrote: >> I agree that C.M. Heard's ideas should

Re: UDP+Fragmentation (was: "Deprecate")

Ron, On Aug 1, 2013, at 10:37 AM, Ronald Bonica wrote: > Cmh, > > When I read this message, my first reaction was to scream "that such a thing > could not possibly be deployed, because operators will filter anything that > they don't know or have an immediate use for." But after a few hallway

Re: UDP+Fragmentation (was: "Deprecate")

On Thu, 1 Aug 2013, RJ Atkinson wrote: > I agree that C.M. Heard's ideas should be explored > in more detail by the IETF. Not just my suggestion, but other ideas as well: - put UDP source and destination ports in a new IPv6 option that and add it along with a fragment header when fragmenting

RE: UDP+Fragmentation (was: "Deprecate")

Hi Ron, SEAL already handles the segmentation/reassembly such that it would not be necessary to define a new UDP. Plus, SEAL can be used independently of any transport layer, e.g., for IP-in-IP tunneling. If you are looking for a replacement for IPv6 fragmentation (which you should be) IMHO SEAL i

Re: UDP+Fragmentation (was: "Deprecate")

I agree that C.M. Heard's ideas should be explored in more detail by the IETF. (I defer to the Powers That Be which list that might belong to -- TSV WG list might be one option, but it is not as likely to have IPv6 operators as well represented as the IPv6 list seems to have.) Yours, Ran ---