[j-nsp] ip(v6) options

[Saku Ytti]

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

Hey

> 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



-- 
  ++ytti