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

[Christopher Morrow <[e-mail]>]

On Tue, Dec 4, 2018 at 5:56 PM C. M. Heard <[e-mail]> wrote:

> On Tue, 4 Dec 2018 15:17:33 -0500 Christopher Morrow wrote:
> > A solution might be to have a mode where  a router may just ignore all
> > headers except the src/dst-ip and simply forward all packets, trusting
> > that the conversing adults will sort out problems with unknown/new/
> > experimental headers or with a tortured ordering of headers (for
> > instance).
>
> Glad to hear you say that, because that's exactly what RFC 7045
> envisions as the default forwarding behavior:
>
>
I'm glad I'm not too nuts :)


>    Any forwarding node along an IPv6 packet's path, which forwards the
>    packet for any reason, SHOULD do so regardless of any extension
>    headers that are present [...]
>
>
this does mean that: "please filter the flarbly protocol traffic, eh-1234"
is going to be very hard to do in the network.


> Recognizing that processing of Hop-by-Hop Options in the fast path is
> costly, RFC 8200 formally dropped the requirement for every router to
> process them by default:
>
>    NOTE: While [RFC2460] required that all nodes must examine and
>    process the Hop-by-Hop Options header, it is now expected that nodes
>    along a packet's delivery path only examine and process the
>    Hop-by-Hop Options header if explicitly configured to do so.
>
>
it's important to note that some platforms can't look beyond a certain
number of headers, and that ordering of the headers us up to the src, which
when they are being mean is ... bad :( Even platforms that can look more
than a few headers deep pay for that with clock cycles, so 100g -> 400g ->
1tbps interfaces are less and less likely to see further into the packet(s).


> What some of us would like to see is a statement in the draft that it's
> just fine to operate this way (Christian Huitema made that suggestion
> earlier in this thread, and so did I in my detailed last-call comments).
>
>
oh, good. I like that idea... noting that: "makes filtering bad traffic
pretty impossible" though.


> Mike Heard
>