> If J Random Hacker in his mom's basement can launch an attack which > takes down your network core because your management planes can't > handle 1Tbit, or more realistically 10gbit, of HBH packets, then that > is categorically a network security issue, even if it is a secondary > effect. security failure is almost always a secondary effect. we usually do not intentionally design in specific security vulnerabilities. well, RH0 i guess; every rule has exceptions. but we don't have to knowingly add an other. perhaps there is a signal here where folk who operate the network worry about the operational consequences of ipv6 protocol purism. perhaps we have seen this before. i suspect we will see it again. > What do we do? > > 1. declare that these routers should be able to process terabits of > HBH packets (or experimental EHs because we don't know whether > experimental EHs are required to be processed HBH or by end points > only). and i presume i can print this rfc on paper and put it in the floppy drive slot of my routers and they will suddenly be able to process terabits of hbh on the slow path. cool! > 2. formally drop the requirement for intermediate routers to process > HBH headers we do not really have an actually deployable choice other than this. > 3. build routers which will take some HBH headers at low packet rates > and drop the rest (+ update rfcs to make this formally compliant). and put this into my routers' floopy slot too? we're talking EXISTING ROUTERS that are just not going to be able to make this happen. if this was an ideal world, i would focus on war, hunger, the resurgence of fascism, etc. an undeployable protocol requirement is pretty far down my priority list. randy
