[j-nsp] ip(v6) options

[Saku Ytti]

Anyone remember from top of their head if or not Trio originally
punted transit IP packets with IP options through lo0 filter or not?

I could have sworn when I tested MX80, I needed forwarding-filters to
limit them.

Now it seems they hit lo0 filter and JTAC considers this to be correct
and by design. I view it wildly broken, because it essentially means,
if you want to allow IP options, you need to do something like this

a) match IP options and match any local DADDR => DROP
b) match IP options => police

As opposed to just do b) in forwarding filters.

Much same as it would be wildly broken to punt TTL exceeded messages
through lo0 filter, or anything else that is not destined to the
router itself.

'JunOS Router Security' book agrees:
-------------
Since optioned packets are not destined to the router itself, a lo0
firewall filter will not be able to intercept them. One can apply the
recommended filter to an incoming interface, but the management of
such a filter is cumbersome - especially for a router with many
interfaces or sub-interfaces. Alternatively, one can apply a filter to
the router forwarding table
-----

But according to JTAC behaviour was changed in Trio. I'm quite
confident it still behaved like this in Trio back in the early days.
And suspect perhaps it was broken during 'ddos protection'
introduction. But my memory may be failing me.

[Adam Vitkovsky]

Hey Saku,

Saku Ytti
Sent: Thursday, January 28, 2016 9:38 PM
Anyone remember from top of their head if or not Trio originally punted
transit IP packets with IP options through lo0 filter or not?

Isn’t there a requirement that packets with IP options needs to be punted to the CPU for processing (process switched) (on every hop)
Although I'd be interested to know if it's the LC CPU or RE CPU handling these then.

Also my understanding of RE filter is that it is passed down to all PFEs in the system -so what you filter there is dropped right at the ingress and only what you permit is then subject to the built in DDoS protection rate-limiters (Junos "static" version of LPTS in XR) before it ends up in CPU (wanted to say RE-CPU but now I'm not that sure, could be LC CPU possibly??? ).

I could have sworn when I tested MX80, I needed forwarding-filters to limit
them.
Now it seems they hit lo0 filter and JTAC considers this to be correct and by
design. I view it wildly broken, because it essentially means, if you want to
allow IP options, you need to do something like this
a) match IP options and match any local DADDR => DROP
b) match IP options => police
As opposed to just do b) in forwarding filters.
Much same as it would be wildly broken to punt TTL exceeded messages
through lo0 filter, or anything else that is not destined to the router itself.

Do you mean the term "discard-TTL_1-unknown" i.e. "from ttl 1 then discard"?
It looks like there's a built in mechanism that filters ingress packets with TTL1 that are not destined to the router - as those would not make out the egress interface because of TTL decremented to 0 anyway.
So it looks like instead of just the source IP and possibly some other fields the whole packet is actually passed up to the CPU (RE/LC) so that the CPU can generate Time Exceeded ICMP message. (if just necessary fields would have been listed in a msg sent to CPU there would be no need to mention packets with TTL1 in the RE filter)
The rate at which these packets are punted to CPU is then subject to built-in DDoS protection.


adam


Adam Vitkovsky
IP Engineer

T: 0333 006 5936
E: ***@gamma.co.uk
W: www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of this email are confidential to the ordinary user of the email address to which it was addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on [phone] or email ***@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https:

[Saku Ytti]

Hey,

Post by Adam Vitkovsky
Isn’t there a requirement that packets with IP options needs to be punted to the CPU for processing (process switched) (on every hop)
Although I'd be interested to know if it's the LC CPU or RE CPU handling these then.

Well not hard requirement, but no one in market needs IP options at
performance, so they're done in software in all platforms that I know
of. This isn't the debate, the debate is if or not they should hit lo0
filter.

Post by Adam Vitkovsky
Also my understanding of RE filter is that it is passed down to all PFEs in the system -so what you filter there is dropped right at the ingress and only what you permit is then subject to the built in DDoS protection rate-limiters (Junos "static" version of LPTS in XR) before it ends up in CPU (wanted to say RE-CPU but now I'm not that sure, could be LC CPU possibly??? ).

Quite. lo0 filter when supported in HW is done at ingress HW, then
packet goes through ddos policer, then static NPU=>LC_CPU ratelimiter,
then RP.

Post by Adam Vitkovsky
Do you mean the term "discard-TTL_1-unknown" i.e. "from ttl 1 then discard"?

No. I mena, what if packets with TTL exceeding were punted through lo0
filter, that would be broken, right? Because you don't want to allow
whole world in your loo0 filters.
So why would IP options be punted through lo0?

Even though they are handled by software, they are not subject to lo0 filtering.

Post by Adam Vitkovsky
It looks like there's a built in mechanism that filters ingress packets with TTL1 that are not destined to the router - as those would not make out the egress interface because of TTL decremented to 0 anyway.

Yes. There used to be resolve policer, then there wasn't for 2 years
or so (when things were dangerously broken) after DDOS protection was
implemented, then it was reintroduced and things are fairly ok now.

Post by Adam Vitkovsky
So it looks like instead of just the source IP and possibly some other fields the whole packet is actually passed up to the CPU (RE/LC) so that the CPU can generate Time Exceeded ICMP message. (if just necessary fields would have been listed in a msg sent to CPU there would be no need to mention packets with TTL1 in the RE filter)
The rate at which these packets are punted to CPU is then subject to built-in DDoS protection.

Yes. But the packets are not subject to lo0. So why should IP options be?

[Jared Mauch]

Post by Saku Ytti
Hey,

Post by Adam Vitkovsky
Isn’t there a requirement that packets with IP options needs to be punted to the CPU for processing (process switched) (on every hop)
Although I'd be interested to know if it's the LC CPU or RE CPU handling these then.

Well not hard requirement, but no one in market needs IP options at
performance, so they're done in software in all platforms that I know
of. This isn't the debate, the debate is if or not they should hit lo0
filter.

Some platforms, eg: ASR9K process these on the LC. I know this as we
had LCs crash from a research team using these options. It only impacted one
LC type and only a specific version of software.

- Jared

[Daniel Verlouw]

Hi,

Post by Saku Ytti
Anyone remember from top of their head if or not Trio originally
punted transit IP packets with IP options through lo0 filter or not?

http://kb.juniper.net/InfoCenter/index?page=content&id=KB30719&actp=search

just came online. Coincidence? :-)

-- Daniel.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Saku Ytti]

On 4 February 2016 at 22:38, Daniel Verlouw <***@shunoshu.net> wrote:

Hey

Post by Daniel Verlouw
http://kb.juniper.net/InfoCenter/index?page=content&id=KB30719&actp=search
just came online. Coincidence? :-)

No. I was being difficult customer and wanted the changed behaviour documented.

I think virtually no Juniper network is aware of this change, and do
not know what is their own policy regarding IP-options is.

Previously, on sane lo0 policy, which is to permit explicitly what you
know you need, and then discard everything else, would produce policy,
which allows transit IP-options to pass.
Today on Trio generation, this policy will drop all transit
IP-options. So it's fair to say, if there was ever possibility to use
IP-options on Internet for something, this is final nail to its
coffin.
I greatly preferred the old behaviour, where lo0 is only for
host-bound traffic, never for transit. But at the same time, I can
understand the rationale, now to control ip-options, you do not have
to have ACL entry in forwarding-filter, which has to inspect /every
packet/. Is this at the same time admission, that forwarding-filters
are not recommended to be used at all? I know several JNRP networks
who have forwarding-filter just for limiting or dropping transit
IP-options.

I did quick test on NLNog ring nodes for some 135k destination pairs,
and 89% of them would not pass 'record route' IP option. Which means
it's safe to say practical use of IP options is not possible in
Internet.
I've few times surprised random networks by telling them 'your router
XYZ has HW/SW FIB mismatch for prefix K', when IP options ping would
pass, normal would not. But it's not really good enough reason to
allow them, imho.
Luckily it also seems that IP options are not actively used as attack
vector, as even on networks which do allow them, very few packets
actually arrive with IP options set. Unluckily, there probably are
packet-of-death parsing etc bugs related to them, as no one uses or
tests them.

This is matter of debate if or not you should pass them, I'm of
opinion that they pose too large security risk and DoS risk and
shouldn't be allowed. Which makes the new Juniper policy good, because
people with good lo0 filter start suddenly dropping them, by upgrading
to Trio boxes.
If you'd want to restore original behaviour, and behaviour of
competitors, you'd need something like this in your lo0 filters -
http://p.ip.fi/5knv.txt

Some other findings from NLNog mass ping, from paths seen in record
route (i.e. routers which accepted and filled it)

Most common domains (constructed in awkward way, first only unique IP
addresses are used, then all are resolved and how many unique domains
within same three-part domain. It may not be very indicative, as
network which is just VAR.domain.com could dominate and would not be
shown here, e.g. he.net is very high here, if we inspect just two
parts. but completely invisible without)

15 ch.as15576.net.
15 ch.vshn.net.
15 core.enta.net.
15 ip.isnet.net.
15 rtr.liquidweb.com.
16 cwt.btireland.net.
20 turktelekom.com.tr.
20 uk.clara.net.
26 static.pccwglobal.net.
26 uk.m247.com.
28 se.portlane.net.
29 ip4.gtt.net.
36 nv.net.il.
37 bx.telstraglobal.net.
46 ring.nlnog.net.
71 bi.telstraglobal.net.
82 core.init7.net.
149 gin.ntt.net.
618 atlas.cogentco.com.


Most common addresses (16 most specific bits masked out):
1182 77.243/16
1236 109.233/16
1337 62.133/16
1507 200.143/16
1520 82.197/16
1574 212.143/16
1667 80.81/16
1884 46.20/16
2419 77.109/16
2436 129.250/16
2591 72.52/16
2615 195.66/16
4250 130.117/16
4661 80.67/16
4662 184.105/16
4976 80.249/16
8661 154.54/16