Brian E Carpenter wrote: > On 12/06/2013 11:58, Sander Steffann wrote: >> Hi, >> >>> My question to th wg is: >>> >>> 1) Do we want to limit the size of the IPv6 header chain? >> I think it is necessary yes. >> >>> 2) If so, which limit should we pick? >> I think there are two conditions here: >> - The full layer-4 header must be within this limit, and it must be in the >> first fragment (if fragmented at all) >> - The limit should be larger than what is currently used + some margin for >> stuff we forgot >> >> Take i.e. Figure 3 of >> http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html >> as example. It shows a Mobile-IPv6 packet: IPv6 header (40 octets) + >> Routing header (24 octets) + Destination Options header (24 octets) + >> Fragmentation header (8 octets). Add to that a basic TCP header (20 octets) >> and we arrive at 116 octets. >> >> So a limit of 128 would currently probably be ok, but I personally would >> prefer the limit to be a bit higher just to have some extra margin. > > I think we should advocate 256 as a target for hardware designers; we know > that > some of them have current hardware limits less than that, but a "SHOULD > inspect 256" > seems reasonable (and conversely, a "SHOULD NOT exceed 256" for hosts > generating > IPv6 packets). > > Given time (as somebody said, maybe ten years) this would palliate the > problem. > > Brian
Whilst I agree we need to take steps to simplify the problem, I'd like some feedback from hardware manufacturers either publicly or privately whether this limit is sufficient on its own. If the packet parser/ forwarding engine is implemented as a byte code machine, it's the attacker who controls what code is executed. 200+ bytes of extension header opcodes could probably still be crafted with a combination of enough pad1's and useful options to tie up around a couple of hundred byte-code-machine cycles before the last option can be processed, whilst also disrupting any prefetch or pipelining optimisations. Then there's almost certainly a direct link between the clock rate of the packet parsing engine and the all important packets per second marketing number. My gut feeling is that we also need to provide more opportunities for parallel processing. regards, RayH -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
