On 4 February 2016 at 22:38, Daniel Verlouw <dan...@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 _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp