Removing fragmentation by definition in an application protocol isn’t even possible in Ipv4 as routers can frag. It seems a large challenge to manipulate any x509 stack and not expect fragmentation? I know we all tend to think of 1514 (IP over 802.3 Ethernet) but MTU is not defined by the endpoints but the path. I think a number of times there has been a discussion of running some session components over tcp which might help with some of the sequencing issues of splitting the transaction? A backwards compatibility challenge is that, while ntp owns udp and tcp 123, I think many existing firewall configurations would drop tcp connections for 123. I don’t know how many autokey deployments are actually running so perhaps it is not that big an issue.
From: ntpwg [mailto:[email protected]] On Behalf Of Sharon Goldberg Sent: Friday, April 01, 2016 6:00 AM To: [email protected] Cc: NTP Working Group; [email protected] Subject: Re: [ntpwg] [TICTOC] WGLC on NTS: Round trips for key exchange EXTERNAL EMAIL Sharon, on phone On Apr 1, 2016, at 8:18 AM, [email protected]<mailto:[email protected]> wrote: > > On Thu, Mar 31, 2016 at 8:59 AM, Miroslav Lichvar > > <[email protected]<mailto:[email protected]>> wrote: > > On Thu, Mar 31, 2016 at 01:58:35PM +0200, > > [email protected]<mailto:[email protected]> wrote: > > > To be honest, we had never assumed for IP fragmentation (on one request > > > and one response) to be a huge problem. > > > > One request and response could still be a problem. If the client is > > not able to receive fragmented packets, it won't be able to initialize > > the NTS association. > > Right, to second that, there are middleboxes that block fragmented packets. > > > > If people see grave problems with it, we would welcome an > > > elaboration as to why this is. > > > > I'm not sure and I was hoping others would comment on that. It seems > > to me problems with IPv4 fragmentation are quite common due to > > firewalls dropping ICMP packets or IP fragments, and IPv6 doesn't seem > > to recommend sending packets larger than 1500. > > To add to that, fragmentation is commonly used as an attack vector. > I would strongly discourage the use of IP fragmentation in what is > supposed to be a security protocol. Please see these references for > a small sampling of examples. Is the issue specific to IP fragmentation of UDP packets? Or to IP fragmentation in general? (I'm assuming it does not apply to all possible kinds of packet fragmentation.) I'm sorry, I have yet to go over the linked documents. All fragmentation. The following paper affects both tcp and udp. https://www.usenix.org/legacy/event/woot11/tech/final_files/Gilad.pdf Again. My point is that we should not be relying on fragmentation in NTS. It regularly leads to unexpected attacks. Also quoting Ron Bonica from the first linked conversation below: "please don't write new applications that fragment packets." Sharon > https://www.nanog.org/sites/default/files/mon.general.fragmentation.bonica.pdf > > http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf > > http://arxiv.org/abs/1205.4011 > > https://media.blackhat.com/bh-eu-12/Atlasis/bh-eu-12-Atlasis- > Attacking_IPv6-WP.pdf > > http://www.iss.net/security_center/reference/vuln/TearDrop.htm > > https://www.offensive-security.com/wifu/Fragmentation-Attack-in-Practice.pdf > > Even if you don't see a SPECIFIC attack on NTS in these papers, my > point is that we can usually find a way to exploit IP fragmentation > in unexpected ways to break security. This has happened over and > over in the last two decades on many different protocols. In fact > this is exactly what we did in our recent NTP paper, Section VI: > > .https://eprint.iacr.org/2015/1020.pdf > > I would strongly object to having NTS rely on IP fragmentation. > This would be a horrible design decision. Noted.
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
