This document proposes using solicited node multicast group (SNMG) membership to mitigate router neighbor cache exhaustion denial-of-service attacks. It describes how routers can collect on-link SNMGs using MLD to determine if an address has nodes associated before performing neighbor discovery. If the SNMG for an unresolved address is absent, the neighbor discovery trigger packet would be dropped. This adds another layer of protection on top of existing RFC6583 mitigations. The document surveys which operating systems support SNMG membership and outlines some limitations and next steps to implement this approach.
Presented on 6 September 2013 in a seminar organised by Progreso Training.
Sign up for free seminars at http://progresotraining.eventbrite.sg or http://www.progreso.com.sg/training/event_view_all.php for an overview of IPv6 Security.
Presented on 6 September 2013 in a seminar organised by Progreso Training.
Sign up for free seminars at http://progresotraining.eventbrite.sg or http://www.progreso.com.sg/training/event_view_all.php for an overview of IPv6 Security.
How to connect FIWARE to Robots ? We discuss how the FIWARE enablers can connect to ROS2, a de facto standard for robotic frameworks, using Fast RTPS and KIARA.
Ведущий: Терренс Гаро
В докладе рассказывается о том, как создать ханипот (ловушку) и организовать сервис с обновляемыми данными о попавшихся DDoS-ботах с помощью Kibana, Elasticsearch, Logstash и AMQP. Докладчик откроет исходный код системы мониторинга и сбора внешней статистики DDoS-атак, над которой он работал со своей командой последние два года.
IPv6: Threats Posed By Multicast Packets, Extension Headers and Their Counter...IOSR Journals
ABSTRACT: Security issues concerning the spreading Internet Protocol version 6 (IPv6) is one of the major
issues in the world of networking today. Since it is not the default network protocol deployed nowadays (but
systems are migrating slowly from ipv4 to ipv6) there are no best practices from the point of network
administrators, nor are any guarantees that implemented IPv6 protocol stacks and security techniques without
any bugs. This paper addresses some security concerns like extensive use of multicast packets and extension
headers and its countermeasures.
Keywords: multicast, extension headers, reconnaissance, rogue dhcpv6 server spoofing, dual-stack,
tunnels, Nat, ping of death
Fiware - communicating with ROS robots using Fast RTPSJaime Martin Losa
How to connect FIWARE to Robots ? We discuss how the FIWARE enablers can connect to ROS2, a de facto standard for robotic frameworks, using Fast RTPS and KIARA.
Ведущий: Пол Викси
Система доменных имен (DNS) предлагает отличный вид на локальную и глобальную сети, что дает возможность исследовать действия киберпреступников и методы атак. В докладе будет показано, как обезопасить DNS и использовать ее для защиты других подключенных объектов. Докладчик подробно расскажет о подмене кэша DNS, расширениях защиты для протокола DNS (DNSSEC), DDoS-атаках, ограничении скорости передачи, межсетевом экране DNS и пассивном DNS-мониторинге.
How to connect FIWARE to Robots ? We discuss how the FIWARE enablers can connect to ROS2, a de facto standard for robotic frameworks, using Fast RTPS and KIARA.
Ведущий: Терренс Гаро
В докладе рассказывается о том, как создать ханипот (ловушку) и организовать сервис с обновляемыми данными о попавшихся DDoS-ботах с помощью Kibana, Elasticsearch, Logstash и AMQP. Докладчик откроет исходный код системы мониторинга и сбора внешней статистики DDoS-атак, над которой он работал со своей командой последние два года.
IPv6: Threats Posed By Multicast Packets, Extension Headers and Their Counter...IOSR Journals
ABSTRACT: Security issues concerning the spreading Internet Protocol version 6 (IPv6) is one of the major
issues in the world of networking today. Since it is not the default network protocol deployed nowadays (but
systems are migrating slowly from ipv4 to ipv6) there are no best practices from the point of network
administrators, nor are any guarantees that implemented IPv6 protocol stacks and security techniques without
any bugs. This paper addresses some security concerns like extensive use of multicast packets and extension
headers and its countermeasures.
Keywords: multicast, extension headers, reconnaissance, rogue dhcpv6 server spoofing, dual-stack,
tunnels, Nat, ping of death
Fiware - communicating with ROS robots using Fast RTPSJaime Martin Losa
How to connect FIWARE to Robots ? We discuss how the FIWARE enablers can connect to ROS2, a de facto standard for robotic frameworks, using Fast RTPS and KIARA.
Ведущий: Пол Викси
Система доменных имен (DNS) предлагает отличный вид на локальную и глобальную сети, что дает возможность исследовать действия киберпреступников и методы атак. В докладе будет показано, как обезопасить DNS и использовать ее для защиты других подключенных объектов. Докладчик подробно расскажет о подмене кэша DNS, расширениях защиты для протокола DNS (DNSSEC), DDoS-атаках, ограничении скорости передачи, межсетевом экране DNS и пассивном DNS-мониторинге.
Die monatlichen Anlässe in Zusammenarbeit mit dem Swiss IPv6 Council behandeln verschiedene technische Themenbereiche von IPv6.
Das Referat von Jen Linkova vom 30. November 2015 widmete sich dem Neighbor Discovery Protokoll, einem Schlüsselmechanismus um Verbindungen zwischen IPv6 Knotenpunkten und LANs aufzubauen. Die Referentin fokussierte sich in der Präsentation auf die technischen Details des Designs, der Implementierung sowie Sicherheitsaspekten.
Gerne stellen wir Ihnen die Präsentation zum Anschauen und Herunterladen zur Verfügung. Haben Sie Feedback zum Event? Wir sind gespannt auf Ihre Meinung.
A brief overview on how networking works on IPv6. I'll try to explain how an ipv6 address is constructed, sub netting, and additional features it has over ipv4. Will try to keep it simple, and only address the core parts.
Using Linux OS stack to transform your Linux Mission Critical Applications into the Active-Active Stretched Cluster Storage with the very high performance NVMe-oF protocol. The slide deck also illustrates various failure scenarios at Networking and Storage levels, down to the very details of how Cluster RAID1 behave in those failure cases.
Fault tolerance at scale, a look at how Apache Cassandra achieves fault tolerance via multi data center and/or multi region replication. Presented by Alex Thompson at the Sydney Cassandra Meetup.
What CloudStackers Need To Know About LINSTOR/DRBDShapeBlue
Philipp explains the best performing Open Source software-defined storage software available to Apache CloudStack today. It consists of two well-concerted components. LINSTOR and DRBD. Each of them also has its independent use cases, where it is deployed alone. In this presentation, the combination of these two is examined. They form the control plane and the data plane of the SDS. We will touch on: Performance, scalability, hyper-convergence (data-locality for high IO performance), resiliency through data replication (synchronous within a site, 2-way, 3-way, or more), snapshots, backup (to S3), encryption at rest, deduplication, compression, placement policies (regarding failure domains), management CLI and webGUI, monitoring interface, self-healing (restoring redundancy after device/node failure), the federation of multiple sites (async mirroring and repeatedly snapshot difference shipping), QoS control (noisy neighbors limitation) and of course: complete integration with CloudStack for KVM guests. It is Open Source software following the Unix philosophy. Each component solves one task, made for maximal re-usability. The solution leverages the Linux kernel, LVM and/or ZFS, and many Open Source software libraries. Building on these giant Open Source foundations, not only saves LINBIT from re-inventing the wheels, it also empowers your day 2 operation teams since they are already familiar with these technologies.
Philipp Reisner is one of the founders and CEO of LINBIT in Vienna/Austria. He holds a Dipl.-Ing. (comparable to MSc) degree in computer science from Technical University in Vienna. His professional career has been dominated by developing DRBD, a storage replication software for Linux. While in the early years (2001) this was writing kernel code, today he leads a company of 30 employees with locations in Austria and the USA. LINBIT is an Open Source company offering enterprise-level support subscriptions for its Open Source technologies.
-----------------------------------------
CloudStack Collaboration Conference 2022 took place on 14th-16th November in Sofia, Bulgaria and virtually. The day saw a hybrid get-together of the global CloudStack community hosting 370 attendees. The event hosted 43 sessions from leading CloudStack experts, users and skilful engineers from the open-source world, which included: technical talks, user stories, new features and integrations presentations and more.
NZNOG 2020 - IETF Highlights for OperatorsMark Smith
A brief overview of IETF RFCs published in the last 6 months that are likely to be of interest to network operators, as well as some current Internet Drafts that may also be of network operator interest.
NZNOG 2020 - Getting IPv6 Private Addressing RightMark Smith
In this presentation I briefly describe the first version of IPv6 private or local network addressing - site-locals - and the issues that caused the IETF to replace them back in the early 2000s.
I then describe their replacement, Unique Local Unicast Addresses.
Finally, I provide an overview of how they are intended to be used in parallel with public IPv6 Internet addresses, without needing to use NAT.
This is a shortened version of the same topic I presented on at AusNOG 2019.
Using a set of Network Critical Success Factors (NCSFs) - things network operators need to get right to run a good network - I then use them to evaluate IPv4 Network Address Translation.
I then look at the fundamental nature of IPv6 (and IPv4), and how it can better suite the two different application communications architectures - client-server and peer-to-peer.
Finally, I describe how some of the perceived benefits of NAT can be achieved with IPv6 without performing address translation.
This is an updated version of my AusNOG 2016 presentation on the same topic.
IETF 106 - IPv6 Formal Anycast Addresses and Functional Anycast AddressesMark Smith
Currently, IPv6 anycast addresses are chosen from within the existing IPv6 unicast address space, with the addresses nominated as anycast addresses through configuration. An alternative scheme would be to have a special class of addresses for use as anycast addresses. This memo proposes a distinct general anycast addressing class for IPv6, and a more specific scheme for functional anycast addresses.
IETF 106 - Default IPv6 Local Only Addressing for Non-Internet DevicesMark Smith
For certain types or models of devices it should be clear and obvious that, by default, they should not be reachable from the global IPv6 Internet, or able to reach the global IPv6 Internet, even though the network they are attached to provides global IPv6 Internet connectivity. This memo proposes that these types of devices refuse to configure and use global IPv6 Internet addresses by default.
IETF 106 - In-flight IPv6 Extension Header Insertion Considered HarmfulMark Smith
In the past few years, as well as currently, there have and are a number of proposals to insert IPv6 Extension Headers into existing IPv6 packets while in flight. This contradicts explicit prohibition of this type of IPv6 packet proccessing in the IPv6 standard. This memo describes the possible failures that can occur with EH insertion, the harm they can cause, and the existing model that is and should continue to be used to add new information to an existing IPv6 and other packets.
AusNOG 2019 - Getting IPv6 Private Addressing RightMark Smith
In my AusNOG 2011 presentation, "Residential IPv6 CPE - What Not to Do and Other Observations", a couple of my examples of mistakes in some IPv6 CPE implementations were the incorrect use and understanding of IPv6 private addressing.
Since then, I've come across other examples of IPv6 private addressing misunderstandings.
In this presentation, I want to help people better understand IPv6 private addressing; when to use it, and if you're using it, how to get it right.
Discussion of IPv6 private addressing naturally leads to the
discussion of one of the most significant features of IPv6 other than the much larger address space; the formal support of nodes (or rather interfaces) having multiple addresses. In the second part of the presentation I'll talk about multi-addressing, including how it works and why it allows a network to have IPv6 private addressing without also having to use any form of NAT to reach the Internet. I'll also talk about some of its other emergent benefits.
At a number of past AusNOG conferences we've seen Google and Facebook make a number of presentations about how they've automated the operatonal deployment, monitoring and troubleshooting in their networks.
They've been really interesting presentations. However, I've wondered how applicable their level of automation really is to the rest of us with much smaller networks. We don't and most of us will never have the scale problems they do.
I've changed my mind. I think Google's and Facebook's level of operational automation is inevitable for all networks. If automation is performed by robots, then I think robots are coming to networks everywhere.
In this presentation, I'll talk about why I've changed my mind. More practically, I'll introduce some of the basic building block tools of "robot building" that can be used to build some trivial yet still quite useful operational automation. These tools can then be used as a basis to build more advanced automation. Finally, I'll talk a bit about the possible "post automation" future in networks.
1. IETF95
Further Mitigating Router ND Cache Exhaustion
DoS Attacks Using Solicited-Node Group
Membership
Mark Smith
markzzzsmith@gmail.com
2. Problem
Router neighbor cache state resource exhaustion denial-of-
service attack.
Remote attacker attempts to consume router ND cache
resources by sending packets to non-existent destinations on
the link.
Described in RFC3756, further described RFC6583 with
suggested mitigations.
3. Solicited Node Multicast Group
Mitigation
Proposal:
Use nodes' Solicited Node Multicast Group
membership to reduce and try to make harder to
find a router's exploitable Neighbor Cache
resources.
4. Solicited Node Multicast Group
(SNMG) Membership
Per RFC4291 and RFC6434, nodes are to join SNMGs for
each of their addresses, using MLDv1 or MLDv2.
Solicited Node Multicast Group:
FF02:0:0:0:0:1:FF00::<lower 24 bits IPv6 address>
where address is either unicast or anycast.
5. Absence of SNMG
Absence of SNMG means no addresses on-link
that map to it.
No point performing ND NS for an address that
would map to an absent SNMG.
6. Method
1) Router collects on-link present SNMGs using
MLDv1 or MLDv2.
2) Packet with unresolved D.A. arrives, SNMG for
unresolved address is calculated.
3) Calculated SNMG is compared with the list of on-
link SNMGs.
4) Perform ND NS if SNMG is present. If not, drop
ND trigger packet. ND Cache DoS furtheroS further
mitigatedmitigated.
7. MLD reliablity?
Two Modes:
Strict Mitigation Mode – drop ND NS trigger packets for
unknown SNMGs when MLD known to be reliable.
e.g., enterprise, content provider networks.
Relaxed Mitigation Mode – drop ND NS trigger packets for
unknown SNMGs only when DoS looks to be happening.
e.g., default for home gateways, public networks
8. Survey of MLD for SNMGs
The following send MLDv1 or MLDv2 joins for SNMGs:
● Linux: Chromecast v1 & v2, Android 6, Chrome OS,
Fedora 20
● Windows: XP, Vista, 7, 8.1
● Apple: Mac OS X, iPhone (thanks to Fred Baker and
Mark Prior)
“MLD Considered Harmful”, Antonios Atlasis et. al.,
presentation says MLD disabled for OpenBSD. (of course, I don't
agree with the title :-) )
9. Limitations
2^40 addresses maps to each SNMG in a /64 prefix. Attacker
guessing or discovering an on-link SNMG can consume ND
cache resources because ND NSes will be sent.
Privacy Addresses or Stable Opaque IIDs, both with random
IIDs, mitigates guessing.
Discovery only possible if attacker is not blind to the success
of the DoS. A link with /104 or shorter prefix length will have
2^24/16 million possible SNMGs.
10. So certainly not perfect!
Could be useful in addition to mitigations in
RFC6583.
11. Next Steps
Current thinking on an implementation:
● pim6sd or mrd6 to collect SNMGs via MLD
● Linux kernel ND code modified to use multicast
route table for SNMG checks
Suggestions appreciated (I'm certainly not an expert kernel hacker!)
Not specifically seeking v6ops WG adoption,
certainly fine with that if that happens.
12. Some other thoughts
Hosts could implement this method if they were willing to
participate in MLD as a “router”. ND cache attacker would be user
on multi-user host – DoS is on other users of the host.
As MLDv2 does not supress reports, LL source addresses could
be used to enumerate all on-link nodes' LL addresses (except
OpenBSD!).
Address registation protocol by combining MLDv2 LL source
collection with hosts supporting Node Information Queries or
Inverse ND?