On Tue, 14 Aug 2018 21:38:35 +0000 Randy Bush <randy@psg.com> wrote:
we would be interested in data from others.
My data is coarse, but with 'show system statistics tcp | match auth' I see sometimes thousands of rcv packets dropped on BGP routers. I doubt they are attacks, but simply badly configured or stale peer sessions over the course of time the counters initialized from. John
My data is coarse, but with 'show system statistics tcp | match auth' I see sometimes thousands of rcv packets dropped on BGP routers. I doubt they are attacks, but simply badly configured or stale peer sessions over the course of time the counters initialized from.
thanks john for the one (so far) answer to my question instead of telling me how to run my routers what i see also looks like config as opposed to attack --- follow-on question: anyone using the timed key-chain stuff? randy
On Aug 14, 2018, at 8:04 PM, Randy Bush <randy@psg.com> wrote:
follow-on question:
anyone using the timed key-chain stuff?
I’ve looked at it, hear it works, but not been willing to take the hit for any transition. I talked about some of this and other challenges at SAAG WG at IETF 101. Transport area has some possible interesting things, but similar to what Haas said, TCP-AO isn’t really viable yet, and we need something that’s stable enough to last 5-7 years, which is very different from a HTTP transaction that may live only a few seconds. We have some places where we could transition non-BGP protocols and rotate the key, but last I recall it was only there on a single vendor so multi-vendor posed some challenges. - Jared
[ again, thanks for an answer to the question asked ]
anyone using the timed key-chain stuff?
I’ve looked at it, hear it works, but not been willing to take the hit for any transition.
and i am not sure it meets my needs. i am not seeking privacy or pfs. i want roll-if-compromise. (and no, i do not want automated compromise heuristics, a recipe for death).
we need something that’s stable enough to last 5-7 years, which is very different from a HTTP transaction that may live only a few seconds.
something such as, or close to, rfc 4808? randy
On Aug 14, 2018, at 8:12 PM, Randy Bush <randy@psg.com> wrote:
[ again, thanks for an answer to the question asked ]
anyone using the timed key-chain stuff?
I’ve looked at it, hear it works, but not been willing to take the hit for any transition.
and i am not sure it meets my needs. i am not seeking privacy or pfs. i want roll-if-compromise. (and no, i do not want automated compromise heuristics, a recipe for death).
we need something that’s stable enough to last 5-7 years, which is very different from a HTTP transaction that may live only a few seconds.
something such as, or close to, rfc 4808?
It provides some capability, but for example if I have a large iBGP mesh and need to change methods of securing it and have automation involved, it can often be a one-shot change unless I can zone some routers to different versions of templating to have a smooth transition. Basically the negative side of using peer-groups can be quite catastrophic with how you transition from the router software without good update packing/replication to one with a good system. It doesn’t need the groups to optimize the leadership replication, but you still use them to minimize configuration duplication. I’m not sure if in 2018 which is the right path from an automation perspective, if you can have software specify and iterate everything, do you continue to use apply-groups, or just rely upon the automation to output the full configuration? Most systems (including the ones at present and past employers) tend to be a variation on template driven in some language(s) where the original problem/engineer creep doesn’t account for the proper abstract models to allow zoned changes/rollover of subsets of the network. Ie: rolling the key is an all-or-nothing operation. Similar to JTK most of the log messages we see are from people who forgot the MD5 key, or at an IX where we did poor relationship management so the IP is now reused by others and nobody cleaned up the older session(s). I have heard (but not personally seen) of well formed TCP session attacks where md5 may have helped, but since the punt path tends to be the weak link and most folks don’t do GTSH/GTSM (or worse, have hardware that can’t filter based on this) you still incur the expensive punt operation only to have the RP/RE kernel then drop the packet. IOS-XR also has very good/robust defaults with LPTS which helps significantly. I’ve seen quite large attacks against a router be mitigated by LPTS and not require the mpp/control plane filters to be involved. Basically, once you roll md5 you may be at risk for having rolled it to need a way to undo and that pathway may not be easy, with or without automation. - Jared
something such as, or close to, rfc 4808?
It provides some capability, but for example if I have a large iBGP mesh and need to change methods of securing it and have automation involved, it can often be a one-shot change unless I can zone some routers to different versions of templating to have a smooth transition. Basically the negative side of using peer-groups can be quite catastrophic with how you transition from the router software without good update packing/replication to one with a good system. It doesn’t need the groups to optimize the leadership replication, but you still use them to minimize configuration duplication.
I’m not sure if in 2018 which is the right path from an automation perspective, if you can have software specify and iterate everything, do you continue to use apply-groups, or just rely upon the automation to output the full configuration?
Most systems (including the ones at present and past employers) tend to be a variation on template driven in some language(s) where the original problem/engineer creep doesn’t account for the proper abstract models to allow zoned changes/rollover of subsets of the network. Ie: rolling the key is an all-or-nothing operation.
Similar to JTK most of the log messages we see are from people who forgot the MD5 key, or at an IX where we did poor relationship management so the IP is now reused by others and nobody cleaned up the older session(s).
I have heard (but not personally seen) of well formed TCP session attacks where md5 may have helped, but since the punt path tends to be the weak link and most folks don’t do GTSH/GTSM (or worse, have hardware that can’t filter based on this) you still incur the expensive punt operation only to have the RP/RE kernel then drop the packet.
IOS-XR also has very good/robust defaults with LPTS which helps significantly. I’ve seen quite large attacks against a router be mitigated by LPTS and not require the mpp/control plane filters to be involved.
Basically, once you roll md5 you may be at risk for having rolled it to need a way to undo and that pathway may not be easy, with or without automation.
one or both of us needs to reread 4808 randy
participants (3)
-
Jared Mauch -
John Kristoff -
Randy Bush