Re: [Tsv-art] [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06

[Randy Bush <[e-mail]>]

> 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