Re: IPv6 Security Frequently Asked Questions (FAQ)

[Mark Andrews]

> On 8 Mar 2019, at 6:30 pm, Fernando Gont  wrote:
> 
> Hello, Mark,
> 
> Thanks for your feedback! Please see in-line
> 
> On 8/3/19 04:10, Mark Andrews wrote:
>> "Generation of IPv6 fragments in response to ICMPv6 PTB messages has been 
>> deprecated in the revised IPv6 specification"
>> 
>> IS INCORRECT
>> 
>> generation of fragments is “discouraged".  Discouraged and deprecated mean 
>> different thing.  
> 
> There is a writeo here. The text should have said "generation of IPv6
> atomic fragments", or,
> 
> "Generation of IPv6 fragments in response to ICMPv6 PTB messages
> advertising an MTU smaller than 1280"
> 
> 
> The whole section refers to "atomic fragments" which might be generated
> even for protocols that are not supposed to employ fragmentation.
> 
> I will clarify this in the next rev.

Thanks

>>  However, the use of such
>>   fragmentation is discouraged in any application that is able to
>>   adjust its packets to fit the measured path MTU (i.e., down to 1280
>>   octets).
>> 
>> the whole of 4.4 is very badly worded and states things as fact which don’t
>> appear in RFC’s at all.
> 
> Please let me know if, considering the writeo I referred to above, you
> still feel the same.

I think I’ll reserve judgement until I have seen the re-write.

>> The adding of a fragmentation header for PTB <1280 has gone.  Fragmentation
>> down to 1280 is still supposed to happen in response to a PTB.  Packets still
>> have to flow through paths that narrow down to 1280.
> 
> Agreed.
> 
> This section is referred to this scenario:
> 
> Say two nodes only mean to employ a TCP-based application (say two BGP
> peers). Say they filter fragments directed to them, since the TCP
> connections will avoid fragmentation.
> 
> In such cases, what would seem as a "safe practice" may be not: if the
> involved systems employ a legacy IPv6 implementation, then an attacker
> can trigger the generation of IPv6 fragments (even for TCP conenctions)
> by spoofing an ICMPv6 PTB claiming an MTU < 1280.
> 
> This is what this section is about: If you are going to drop fragments,
> make sure you also take care of ICMPv6 PTBs, since they may trigger
> fragmentation even for protocols that you'd assume would never emply
> fragmentation.
> 
> Thanks!
> 
> Cheers,
> -- 
> Fernando Gont
> SI6 Networks
> e-mail: fg...@si6networks.com
> PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: IPv6 Security Frequently Asked Questions (FAQ)

[Fernando Gont]

Hello, Mark,

Thanks for your feedback! Please see in-line

On 8/3/19 04:10, Mark Andrews wrote:
> "Generation of IPv6 fragments in response to ICMPv6 PTB messages has been 
> deprecated in the revised IPv6 specification"
> 
> IS INCORRECT
> 
> generation of fragments is “discouraged".  Discouraged and deprecated mean 
> different thing.  

There is a writeo here. The text should have said "generation of IPv6
atomic fragments", or,

 "Generation of IPv6 fragments in response to ICMPv6 PTB messages
advertising an MTU smaller than 1280"


The whole section refers to "atomic fragments" which might be generated
even for protocols that are not supposed to employ fragmentation.

I will clarify this in the next rev.


> 
>   However, the use of such
>fragmentation is discouraged in any application that is able to
>adjust its packets to fit the measured path MTU (i.e., down to 1280
>octets).
> 
> the whole of 4.4 is very badly worded and states things as fact which don’t
> appear in RFC’s at all.

Please let me know if, considering the writeo I referred to above, you
still feel the same.


> 
> The adding of a fragmentation header for PTB <1280 has gone.  Fragmentation
> down to 1280 is still supposed to happen in response to a PTB.  Packets still
> have to flow through paths that narrow down to 1280.

Agreed.

This section is referred to this scenario:

Say two nodes only mean to employ a TCP-based application (say two BGP
peers). Say they filter fragments directed to them, since the TCP
connections will avoid fragmentation.

In such cases, what would seem as a "safe practice" may be not: if the
involved systems employ a legacy IPv6 implementation, then an attacker
can trigger the generation of IPv6 fragments (even for TCP conenctions)
by spoofing an ICMPv6 PTB claiming an MTU < 1280.

This is what this section is about: If you are going to drop fragments,
make sure you also take care of ICMPv6 PTBs, since they may trigger
fragmentation even for protocols that you'd assume would never emply
fragmentation.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Re: IPv6 Security Frequently Asked Questions (FAQ)

[Mark Andrews]

"Generation of IPv6 fragments in response to ICMPv6 PTB messages has been 
deprecated in the revised IPv6 specification"

IS INCORRECT

generation of fragments is “discouraged".  Discouraged and deprecated mean 
different thing.  

However, the use of such
   fragmentation is discouraged in any application that is able to
   adjust its packets to fit the measured path MTU (i.e., down to 1280
   octets).

the whole of 4.4 is very badly worded and states things as fact which don’t
appear in RFC’s at all.

The adding of a fragmentation header for PTB <1280 has gone.  Fragmentation
down to 1280 is still supposed to happen in response to a PTB.  Packets still
have to flow through paths that narrow down to 1280.

> On 8 Mar 2019, at 5:42 pm, Fernando Gont  wrote:
> 
> Folks,
> 
> The Internet Society has posted the "IPv6 Security Frequently Asked
> Questions (FAQ)" I authored.
> 
> The document is available (in HTML, and also easy-to-print PDF) at:
> 
> https://www.internetsociety.org/deploy360/ipv6/security/faq/
> 
> If you think there are other questions that should be added, or have
> comments on the answers, please do let me know -- the document can
> eventually be revised.
> 
> Thanks!
> 
> Cheers,
> -- 
> -- 
> Fernando Gont
> SI6 Networks
> e-mail: fg...@si6networks.com
> PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

IPv6 Security Frequently Asked Questions (FAQ)

[Fernando Gont]

Folks,

The Internet Society has posted the "IPv6 Security Frequently Asked
Questions (FAQ)" I authored.

The document is available (in HTML, and also easy-to-print PDF) at:

https://www.internetsociety.org/deploy360/ipv6/security/faq/

If you think there are other questions that should be added, or have
comments on the answers, please do let me know -- the document can
eventually be revised.

Thanks!

Cheers,
-- 
-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Re: Arista Layer3

[Colton Conor]

So how does the  7280SR-48C6 compare to the  SLX9540? They are the same
Broadcom chipset right? So the real question, is how does the product
differ in software?



On Wed, Mar 6, 2019 at 10:58 AM Kaiser, Erich  wrote:

> Agreed.
>
>
> On Wed, Mar 6, 2019 at 2:16 AM Brandon Martin 
> wrote:
>
>> On 3/6/19 12:36 AM, Colton Conor wrote:
>> > How much do these boxes cost?
>>
>> List is about $100k in North America for a 9640 with all the ports
>> "unlocked", full hardware kit (PSUs, fans, etc.) and some
>> maintenance/support.  Take whatever your standard Brocade/Extreme
>> discount from that tends to look like.  I should hope nobody pays list
>> or anywhere close.
>> --
>> Brandon Martin
>>
>

Re: WIndows Updates Fail Via IPv6 - Update!

[Saku Ytti]

On Thu, Mar 7, 2019 at 8:33 PM Stephen Satchell  wrote:

> OK, OK, so I will continue to rate-limit both, to reasonably high limits
> on the order of 250/second.  Absent a DoS, it allows network operators
> to use these tools as they should.
>
> My logs show no harm except to attack traffic.
>
> Everything in moderation.

Yes this is fair, all untrusted traffic to control-plane should be
limited. But the question was, what about ICMP types you don't know
about, like timestamps, is it fair to drop those just because we
didn't know about them? What are the risks? Essentially timestamp it's
just echo which happens to have timestamp from each side, hard to
imagine a threat if ICMP echo is not also considered a threat. And
massive benefit in diagnostics if you are able tell that issue is
unidirectional and which direction is the culprit.

Similarly, what about the ICMP type which doesn't exist yet? Should
that be victim of our protection mechanism? This is essentially the
reason why we can't introduce new L4 protocols, because Internet is
full of networks on autopilot with legacy policies where we drop
things we don't know about, without having any specific realised
threat or way to test if that threat is still valid.
And even if there are threats, remember ICMP echo f00fc7c8, +++ or
plethora of crash bugs? We still run ICMP echo, because the diagnostic
value exceeds the cost of the risk.

What tools and protocols are we missing, because we never specify them
as we know they would never work in practice? We have beautiful,
expressive, extendible protocols and then operational policies which
nullify that.
We recently had crash bug in pseudowire LSP ping, but it gives us
operational benefits so we'll just address the bug and we will
continue using the tool. Threat was realised, but it was lower cost
than the cost of losing the tool.

-- 
  ++ytti

Re: WIndows Updates Fail Via IPv6 - Update!

[Stephen Satchell]

On 3/7/19 8:10 AM, Saku Ytti wrote:
> So why not disable ICMP Echo and UDP traceroute, those kids using
> network diagnostics don't need them.
> 
> For clue constrained audience fear will always be the most compelling 
> argument.

OK, OK, so I will continue to rate-limit both, to reasonably high limits
on the order of 250/second.  Absent a DoS, it allows network operators
to use these tools as they should.

My logs show no harm except to attack traffic.

Everything in moderation.

Re: WIndows Updates Fail Via IPv6 - Update!

[Saku Ytti]

On Thu, Mar 7, 2019 at 6:06 PM  wrote:

> Sure I get it it's a very valid and a noble point,
> But what you're asking is let it break (yes potentially -it's just 
> probability until it happens) for 1000s of subs just so that one kiddo has a 
> working niche feature, I can already see what board has to say about that 
> -screw that kid we have money to make there's our brand at stake (yes again 
> just potentially -it's just probability until it actually happens) -but 
> you'll already know what they're gonna say.
> So yes on a technical level I agree with you, but on a commercial level it's 
> a tough case to make.

So why not disable ICMP Echo and UDP traceroute, those kids using
network diagnostics don't need them.

For clue constrained audience fear will always be the most compelling argument.

-- 
  ++ytti

RE: WIndows Updates Fail Via IPv6 - Update!

[adamv0025]

Hey Saku,

> From: Saku Ytti 
> Sent: Thursday, March 7, 2019 3:29 PM
> 
> On Thu, Mar 7, 2019 at 5:19 PM  wrote:
> 
> > From past experience my assumptions would be more along the lines of if
> it's not mainstream there's a higher likelihood that it might trigger 
> exceptions
> in code.
> 
> My point is, let it break. Don't pre-emptively drop things that you don't know
> to be harmful, but where dropping definitely is harmful.
> 
> After risk has realised you have more data about the risk. If it has never
> realised you have no idea. If we extrapolate this culture of fear, we will 
> only
> have HTTPS open, nothing else, and we have to build then next-gen stuff as
> an overlay using HTTPS transport.
> 
Sure I get it it's a very valid and a noble point, 
But what you're asking is let it break (yes potentially -it's just probability 
until it happens) for 1000s of subs just so that one kiddo has a working niche 
feature, I can already see what board has to say about that -screw that kid we 
have money to make there's our brand at stake (yes again just potentially -it's 
just probability until it actually happens) -but you'll already know what 
they're gonna say.
So yes on a technical level I agree with you, but on a commercial level it's a 
tough case to make.

And the same logic applies to the other thread around BGP communities 
filtering...
 
adam

RE: Best practices for BGP Communities

[adamv0025]

> From: NANOG  On Behalf Of Arnold Nipper
> Sent: Wednesday, March 6, 2019 6:57 PM
> 
> On 04.03.2019 19:15, John Kristoff wrote:
> > On Mon, 4 Mar 2019 01:42:02 +
> > Joshua Miller  wrote:
> >
> >> A while back I read somewhere that transit providers shouldn't delete
> >> communities unless the communities have a specific impact to their
> >> network, but my google-fu is failing me and I can't find any sources.
> >
> > Perhaps you're referring to this recent work?
> >
> >   
> >
> 
> See also
> 
>  https://2019.apricot.net/assets/files/APKS756/weaponizing-bgp-using-
> communities.pdf
> 
> 
And the list goes on...
Route-target extended community anyone? Yup I'm talking about routes being 
injected to your L3VPN customers'/services' routing-instances(VRFs).

adam

Re: WIndows Updates Fail Via IPv6 - Update!

[Saku Ytti]

On Thu, Mar 7, 2019 at 5:19 PM  wrote:

> From past experience my assumptions would be more along the lines of if it's 
> not mainstream there's a higher likelihood that it might trigger exceptions 
> in code.

My point is, let it break. Don't pre-emptively drop things that you
don't know to be harmful, but where dropping definitely is harmful.

After risk has realised you have more data about the risk. If it has
never realised you have no idea. If we extrapolate this culture of
fear, we will only have HTTPS open, nothing else, and we have to build
then next-gen stuff as an overlay using HTTPS transport.


-- 
  ++ytti

RE: WIndows Updates Fail Via IPv6 - Update!

[adamv0025]

> From: Saku Ytti 
> Sent: Tuesday, March 5, 2019 3:00 PM
> 
> On Tue, Mar 5, 2019 at 4:54 PM  wrote:
> 
> > Let me play a devil's advocate here, the above statement begs a question
> then, how do you know all that is harmful would you test for every possible
> extension and hw/sw permutation?
> > So there would be 3 sets (though lines might be blurred) known safe,
> known harmful and the biggest of them unknown unknowns.
> > Now as an operator of a commercial network (i.e. your customers like it
> mostly up) wouldn't you do a calculated risk evaluation and opt for the
> known safe -which you know 99% of your customers use and block the rest
> while pissing off the remaining 1%?
> > I know it sounds awful (like a calculations for vehicle safety recalls), 
> > but ...
> 
> 
> Fear is excellent marketing tool, as we can see in politics, works every time.
> But I rather fix realised problems, rather than make unprovable assumptions
> of actions yielding to net benefit. The assumption here is, if we just allow
> ICMP types A, B and C we are gaining in security, can we substantiate that
> claim at all? We can substantiate easily that the proposed ICMP filter breaks
> real useful ICMP tooling.
> 
> 
>From past experience my assumptions would be more along the lines of if it's 
>not mainstream there's a higher likelihood that it might trigger exceptions in 
>code.  

adam