[193357] in North American Network Operators' Group
Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)
daemon@ATHENA.MIT.EDU (Saku Ytti)
Thu Jan 12 15:06:31 2017
X-Original-To: nanog@nanog.org
In-Reply-To: <CAG6TeAtinWMtjZshd-MbhXgx-L4BbWXE3-B8Mvx3TMHHH_UEOg@mail.gmail.com>
From: Saku Ytti <saku@ytti.fi>
Date: Thu, 12 Jan 2017 22:06:27 +0200
To: Fernando Gont <fgont@si6networks.com>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
On 12 January 2017 at 21:53, Fernando Gont <fgont@si6networks.com> wrote:
> besides, becaude of ipv6 ehs, you're not really guaranteed to receive e.g.
> the tcp header in the embedded payload (the embedded payload could easily be
> fixed ipv6 header + ehs).
If the CoPP drops what has not been explicitly allowed, then packets
with EH should be dropped. Particularly if you're not allowing 'tcp'
but you're allowing 'next-header tcp'. I.e. the real BGP session (that
attacker is trying to disrupt) would not have EH, on account that it
would not come up if it had.
But I agree if you do need and do use EH, things can get really dirty
really fast, fundamentally no one implements standard compliant IPv6,
if we're insisting that even pathological EH chains should work (which
is fair viewpoint, while not one that I share).
Maybe embedded flow-label could used to add confidence ICMP message is
for packet we've actually sent? Make flow-label hash, a'la syn cookie.
Spooffed ICMP message to disrupt existing TCP isn't novel.
Coincidentally one service I use stopped working yesterday, but just
for me, after short debugging, there was route cache entry on the
server for my client ip which needed to be flushed, perhaps ended up
there due to rogue ICMP redirect.
--
++ytti
