in addition to those
recently announced
we’ve identified two more suitable talks for the TelcoSecDay 😉
These are
Ravishankar Borgaonkar – TelcoSecurity Mirage: 1G to 5G
Synopsis: The evolution of the mobile networking technology from 1G to 5G is
driving the needs of our modern Digital Society. In this talk, we visit the
security pillars of these technologies and discuss if 5G can strengthen them or
not from an end-users perspective. In particular, we try to fill up security
requirements for 5G networks based on the ongoing design direction.
This is the sequel to the similar post on
“IPv6-related Requirements for the Internet Uplink or MPLS Networks“.
As mentioned there these requirements were created in the course of an RfP for
network security services. The goal of this document was to provide a check list
of IPv6-related requirements that security devices being part of the individual
providers’ offerings have to fulfill in order to fully support the future IPv6
network.
At Troopers15 there will be another
TelcoSecDay, like in the years before
(2014,
2013,
2012). Here’s the
first three talks (of overall 5-6):
Luca Bruno: Through the Looking-Glass, and What Eve Found There
Synopsis: Traditionally, network operators have provided some kind of public
read-only access to their current view of the BGP routing table, by the means of
a “looking glass”.
In this talk we inspect looking glass instances from a security point of view,
showing many shortcomings and flaws which could let a malicious entity take
control of critical devices connected to them. In particular, we will highlight
how easy it is for a low-skilled attacker to gain access to core routers within
multiple ISP infrastructures.
Similar to the documents we
released for Linux
and
Windows (and
actually inspired by a comment to the post on the Linux
guide) Antonios wrote another guide, this
time for Mac OS X.
It can
be found here.
We hope some of you might find it helpful.
Have a great day
One of the main DHCPv6 enhancements – fyi: we have already discussed DHCPv6
in some other posts – many
practitioners have been waiting for quite some time now, is full support of
RFC 6939 (Client Link-Layer Address
Option in DHCPv6) by network devices (acting as relays) and DHCPv6 servers. RFC
6939 support would allow a number of things which large organizations use in
their DHCPv4 based networks, incl.
reservations (assigning a kind-of fixed DHCP address based on the MAC address
of a system which in turn allows for “centralized administration of somewhat
static addresses”).
correlation of IPv4 and IPv6 addresses of a given host identified by its MAC
address.
(some type) of security enforcement based on the MAC address of a host
gathered in the course of a DHCP exchange (see for example slide #29 of
this presentation of the IPv6 deployment at CERN,
btw: slide #9 might be helpful when discussing IPv6 transition plans with
your CIO. or not).
So far it seemed very few components support RFC 6939. When
Tim Martin mentioned at Cisco Live that Cisco
devices running IOS XE support it by default, we decided go to the lab ;-).
We’re currently involved in a complex RfP procedure for global network services
of a large organization. As part of that we were asked to define a list of IPv6
related requirements as for the Internet uplink and MPLS circuit connections.
The involved service providers/carrier offerings will be checked to comply with
those.
As a source of inspiration we mainly used the excellent
“What To Ask From Your Service Provider About IPv6”
document from Cisco, and enhanced that with stuff we observed in other
environments (go wrong), namely with regard to MTU/PMTUD and in the
space of prefix filtering.
Here’s the first draft list we came up with:
Originating from a customer IPv6 deployment project, in early 2014 we defined a
number of requirements as for the IPv6 capabilities of IPAM solutions, with a
certain focus on security-related requirements (due to the specific environment
of the project). We subsequently performed a practical evaluation of several
commercial solutions, based on documentation, lab implementation and vendor
communication.
We just released
a newsletter describing the requirements and the results of the evaluation.
It
should be noted that in the interim newer versions of the evaluated products
might be available which might have enhanced features. Hence, from our
perspective, understanding the requirements of an individual environment might
even be more important than the actual results described in that document (as
those only reflect a certain point of time). We hope to contribute here to a
well-informed requirements definition and decision taking process on your
side.
Feel free to get back to us on any of the points laid out or, even better, join
us at the Troopers
IPv6 Security Summit
in Heidelberg on Mar 16th/17th in order to discuss any related points.
During our blogpost regarding
DHCPv6 Guard evasion,
one of the side-effects was that Access Control Lists (ACLs) configured to block
access to UDP ports 546 can be evaded by abusing (again) IPv6 Extension headers.
Having that in mind, we decided to check the effectiveness of Cisco IPv6 ACLs
under various scenarios. Our goal was to examine whether the IPv6 ACLs of Cisco
routers can be evaded, as well as under which conditions this can take place. To
this end, several representative scenarios from enterprise environments or other
potential ones are examined.
I’ve discussed the heavy complexity of IPv6 and its negative impact on security
architectures relying on state – you know, “stateful” firewalls and the like
😉 – before
(here
and
here.
btw, the widely discussed
IPv6-related network outage
at MIT last year was a state problem as well: switches keeping
track of multicast groups, of which in turn many existed due privacy extensions
combined with the
unfortunate relationship of MLD and ND).
One of the conclusions I’ve drawn in the past was recommending to minimize the
amount of state one might use within security architectures in the IPv6 world.
First, this is bad news for quite some well-established security controls that
need a certain amount of state to work properly, like IDPS systems – which
subsequently
have hard times to work properly
in IPv6 networks.
Secondly there’s another severe caveat. As I fully realized yesterday, at Cisco
Live Europe, in Andrew Yourtchenko‘s excellent
breakout session on “Advanced IPv6 Security in the Core”, this carries some
consequences for stateless (and hence: seemingly “unaffected”) security
controls, too.
We’ve finalized the agenda for this year’s IPv6 Security Summit. Here’s an
overview of the event:
The “IPv6 Security Summit” is a special two-day convention in the context of the
Troopers security conference. It will be
run in two tracks of both half-day workshops and 90 minute presentations on
specific topics. The goal is to foster the discussion of IPv6 security aspects &
issues and to provide practical advice for security officers, network planners
and practitioners in the IPv6 security field.