(IETF I-D) Implications of IPv6 Addressing on Security Operations (Fwd: New Version Notification for draft-ietf-opsec-ipv6-addressing-00.txt)
Folks, The IETF OPSEC WG has adopted our IETF I-D entitled "Implications of IPv6 Addressing on Security Operations". The IETF-ID is available at: * TXT: <https://www.ietf.org/archive/id/draft-ietf-opsec-ipv6-addressing-00.txt> * HTML: <https://datatracker.ietf.org/doc/html/draft-ietf-opsec-ipv6-addressing> We have tried to make the document as practical as possible for anyone doing security operations. Your comments and suggestions will be highly appreciated. P.S.: Thanks to those of you that sent feedback for previous revision of this document, by the way! Regards, Fernando Forwarded Message Subject: New Version Notification for draft-ietf-opsec-ipv6-addressing-00.txt Date: Fri, 02 Jun 2023 07:26:18 -0700 From: internet-dra...@ietf.org To: Fernando Gont , Guillermo Gont A new version of I-D, draft-ietf-opsec-ipv6-addressing-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-ietf-opsec-ipv6-addressing Revision: 00 Title: Implications of IPv6 Addressing on Security Operations Document date: 2023-06-02 Group: opsec Pages: 13 URL: https://www.ietf.org/archive/id/draft-ietf-opsec-ipv6-addressing-00.txt Status: https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-addressing/ Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-opsec-ipv6-addressing Abstract: The increased address availability provided by IPv6 has concrete implications on security operations. This document discusses such implications, and sheds some light on how existing security operations techniques and procedures might need to be modified accommodate the increased IPv6 address availability. The IETF Secretariat
Re: (IETF I-D): Implications of IPv6 Addressing on Security Operations (Fwd: New Version Notification for draft-gont-opsec-ipv6-addressing-00.txt)
Hi, Daniel, On 7/2/23 21:20, Daniel Marks via NANOG wrote: Anecdotal but I've seen hacked AWS accounts with Cloudformation scripts to create and destroy lots of tiny instances to rotate through IPv4 addresses. As with everything, the question is always "what's the level of effort that is required". If an attacker is given the option to: 1) Hack an AWS account, and then script the creation of through-away VMs just to be able to change the IP address each time, or, 2) Stay on the same machine, and be able to (even legitimately) use 2**64 addresses without even the need to hack any terraform scripts They will probably go for #2. And aside of their choices, #1 requires more skills than #2. Being able to rotate through IP addresses is not a new thing, I'm sure we all have networks in mind when we think of garbage/malicious traffic just over IPv4 alone. The difference is in the scale at which this is possible with IPv6, and how high (or low) the bar is to do it. There are some strange implementations of IPv6 that end up having a lot of dissociated users grouped together in a /64 (i.e. Linode, AT Wireless, etc) Therein probably lies some good advice .. i.e., that to the extent that is possible, folks refrain from sharing the same /64 across unrelated/disassociated users. Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
Re: (IETF I-D): Implications of IPv6 Addressing on Security Operations (Fwd: New Version Notification for draft-gont-opsec-ipv6-addressing-00.txt)
On 7/2/23 21:43, Sabri Berisha wrote: - On Feb 7, 2023, at 4:20 PM, nanog nanog@nanog.org wrote: Hi, Anecdotal but I've seen hacked AWS accounts with Cloudformation scripts to create and destroy lots of tiny instances to rotate through IPv4 addresses. If only AWS would care about hacked AWS accounts. Do they lose or earn money when accounts are hacked? -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
Re: (IETF I-D): Implications of IPv6 Addressing on Security Operations (Fwd: New Version Notification for draft-gont-opsec-ipv6-addressing-00.txt)
Hi, Bill, On 7/2/23 01:26, William Herrin wrote: On Mon, Feb 6, 2023 at 7:40 PM Fernando Gont wrote: On 7/2/23 00:05, William Herrin wrote: On the one hand, sophisticated attackers already scatter attacks between source addresses to evade protection software. Whereas in the IPv6 case , you normally have at least a /64 without restriction. You might have a /56 or /48 thanks to your ISP, or simply a /48 thanks to some free tunnelbroker provider... That's not what's actually happening. Well, this *is* happening. -- trust me :-) What's happening is a mix of your computer gets one address unless you bother to enable DHCP/PD, or your CPE gets an IPv6 block and your computer does SLAAC and/or DHCP to assign itself a single IPv6 address. A lot of the probing is coming from hijacked computers, so they have the address they have. Sophisticated attackers can do more with the address blocks they get from their own service providers. But sophisticated attackers could spin up VMs with stolen credit cards, hijack BGP and do all manner of things with IPv4 and IPv6 too. You can use a /48 pretty legitimately without stealing any credit cards or spinning extra VMs... Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
Re: (IETF I-D): Implications of IPv6 Addressing on Security Operations (Fwd: New Version Notification for draft-gont-opsec-ipv6-addressing-00.txt)
Hi, Bill, Thanks for your feedback! In-line On 7/2/23 00:05, William Herrin wrote: On Mon, Feb 6, 2023 at 6:43 PM Fernando Gont wrote: On 6/2/23 20:39, Owen DeLong wrote: After all, they’re only collecting addresses to ban at the rate they’re actually being used to send packets. Yeah, but the whole point of banning is that the banned address is actually used by an attacker subsequently, You both have valuable points here. Listen to each other. On the one hand, sophisticated attackers already scatter attacks between source addresses to evade protection software. Attackers who don't have control over their computer's IP address do not. This is not new and IPv6 does not really change that picture. ... although the ability to change IP addresses in IPv4 is rather limited. -- e.g., if I want do do it at home, I could do a DHCP release and try to get a different lease.. but not very practical -- and certainly not possible in a e.g. cafe scenario. Whereas in the IPv6 case , you normally have at least a /64 without restriction. You might have a /56 or /48 thanks to your ISP, or simply a /48 thanks to some free tunnelbroker provider... On the other hand, there are so many addresses in a /64 that an attacker can literally use a fresh one for each and every probe he sends. Without a process for advancing the /128 ban to a /64 ban (and releasing it once activity stops), reactive firewalls are likely to become less and less effective. Not just /128 to /64, but also e.g. /64 to /56 or possibly /48... Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
Re: (IETF I-D): Implications of IPv6 Addressing on Security Operations (Fwd: New Version Notification for draft-gont-opsec-ipv6-addressing-00.txt)
Hi, Owen, On 6/2/23 20:39, Owen DeLong wrote: As long as they have a reasonable expiry process, it could work. What, specifically? Banning /128s? After all, they’re only collecting addresses to ban at the rate they’re actually being used to send packets. Yeah, but the whole point of banning is that the banned address is actually used by an attacker subsequently, In other words, if: 1. The attacker employs one address for malicious purposes 2. You ban that address 3. The attacker changes the his/her address and goes back to #1 ... you´d be doing yourself a disservice by adding addresses to the ban-list. You just pay penalties for no actual gain. While that’s nota. Completely effective throttle, as long as your expiry process can keep up and your TTL doesn’t exceed your ring buffer size, it should be theoretically OK. Memory is a limited resource. As soon as you consistently use memory iptables-rules slot to store more and more rules/addresses youĺl get no benefit from, the attacker is winning Thanks! Regards, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
(IETF I-D): Implications of IPv6 Addressing on Security Operations (Fwd: New Version Notification for draft-gont-opsec-ipv6-addressing-00.txt)
Hi, All, Recently, I happened to participate in an IPv6 deployment meeting with some large content provider, and said meeting included a discussion about how to mitigate some attacks using block-lists. These folks argued that they ban offending IPv6 addresses as /128s, following IPv4 practices. So it seemed to me that some of the implications arising from the increased IPv6 address space were non-obvious to them. -- that has been the motivation for the publication of this document. * TXT: https://www.ietf.org/archive/id/draft-gont-opsec-ipv6-addressing-00.txt * HTML: https://www.ietf.org/archive/id/draft-gont-opsec-ipv6-addressing-00.html Comments welcome! P.S.: The document is targeted at the IETF opsec wg (https://www.ietf.org/mailman/listinfo/opsec), but I'll be happy to discuss it on this mailing-list, off-list, or at the opsec wg mailing-list... Thanks! Regards, Fernando Forwarded Message Subject: New Version Notification for draft-gont-opsec-ipv6-addressing-00.txt Date: Thu, 02 Feb 2023 19:48:40 -0800 From: internet-dra...@ietf.org To: Fernando Gont , Guillermo Gont A new version of I-D, draft-gont-opsec-ipv6-addressing-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-opsec-ipv6-addressing Revision: 00 Title: Implications of IPv6 Addressing on Security Operations Document date: 2023-02-02 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/archive/id/draft-gont-opsec-ipv6-addressing-00.txt Status: https://datatracker.ietf.org/doc/draft-gont-opsec-ipv6-addressing/ Htmlized: https://datatracker.ietf.org/doc/html/draft-gont-opsec-ipv6-addressing Abstract: The increased address availability provided by IPv6 has concrete implications on security operations. This document discusses such implications, and sheds some light on how existing security operations techniques and procedures might need to be modified accommodate the increased IPv6 address availability. The IETF Secretariat
Windows 11 now implements RFC 7217 (stable privacy addresses)!
Folks, After over 10 (yes, *ten*) years, we have finally addressed security/privacy issues in the generation of IPv6 stable addresses in most popular operating systems. The traditional scheme/algorithm to generate stable IPv6 addresses with SLAAC required that the underlying MAC address be employed to generate the Interface Identifier. That is, the underlying MAC address would be embedded in the lower bits of an IPv6 address. This scheme allowed for host-tracking (since MAC addresses are usually globally-unique), address scanning (since addresses will follow specific patterns) and a number of other issues. In 2011, I submitted an IETF Internet-Draft proposing a scheme for generating stable addresses with SLAAC, meant to replace the traditional scheme. The scheme could be summarised and simplified as: Interface_ID = Hash(Prefix, Secret). Thus, interface identifiers would be stable within the same subnet, but vary across subnets. [Replacing the traditional scheme with this new scheme was anything but easy -- if you're curious, please check the "IPv6 Addressing" section in <https://www.si6networks.com/2020/08/06/a-brief-history-of-recent-advances-in-ipv6-security-part-i/> ] Over time, popular operating systems and packages adopted the proposed algorithm: the Linux kernel, NetworkManager, OpenBSD's slaacd, MacOS, etc. Eventually, virtually every popular OS had adopted the scheme except Windows. Based on a recent note by Brian Carpenter, I ended up testing Windows 11, and I can confirm that it does implement RFC 7217 / RFC 8064! Therefore, e.g. if multiple prefixes are employed on a subnet, the stable addresses for each of such prefixes will employ a different Interface Identifier, thus avoiding the security/privacy issues discussed above -- this is really good news! Unfortunately, Windows still generates temporary addresses with the algorithm specified in RFC 4941, thus resulting in all temporary addresses for a given interface employing the same Interface Identifier (!). This problem has been addressed in RFC 8981... but it's implementation is not yet widespread, yet (it has been incoporated in e.g. the Linux kernel, though). I just hope it doesn't take Windows and others yet another 10+ years to implement RFC 8981, to finally address the remaining security/privacy issues in IPv6 address generation! [Original article with screenshots: https://www.linkedin.com/posts/fernandogont_after-over-10-yes-ten-years-we-have-activity-7008316664207290368-Wcto ] Thanks! Regards, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
Re: Mitigating the effects of SLAAC renumbering events (draft-ietf-6man-slaac-renum)
Hi, On 31/8/22 09:43, Vasilenko Eduard wrote: Hi all, The router could split information between RAs (and send it at different intervals). It may be difficult to guess what is stale and what is just "not in this RA". You ask the router, and the router responds. If you want to consider the case where the router intentionally splits the options into multiple packets (which does not exist in practice), AND the link is super lossy, you just increase the number of retransmissions. There's no guessing. Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
Mitigating the effects of SLAAC renumbering events (draft-ietf-6man-slaac-renum)
Folks, We have been discussing the potential problems associated with SLAAC renumbering events for a while now -- one of the most common cases being ISPs rotating home prefixes, and your devices ending up with stale/invalid addresses. We have done quite a bit of work already: * Problem statement: https://datatracker.ietf.org/doc/html/rfc8978 * CPE recommendations: https://datatracker.ietf.org/doc/html/rfc9096 But there's still some work to do to address this issue: The last remaining it is to improve SLAAC such that hosts can more gracefully deal with this renumbering events. In that light, IETF's 6man has been working on this document: https://www.ietf.org/archive/id/draft-ietf-6man-slaac-renum-04.txt And we have proposed a simple algorithm for SLAAC (an extension, if you wish) that can easily help, as follows: If you (host) receive an RA that contains options, but not all of the previously-received options/information, simply send a unicast RS to the local-router, to verify/refresh that such missing information is still valid. If the information is stale, get rid of it. I presented this algorithm at the last IETF meeting (https://youtu.be/eKEizC8xhhM?t=1308). (You may find the slides here: https://datatracker.ietf.org/meeting/114/materials/slides-114-6man-improving-the-robustness-of-stateless-address-autoconfiguration-slaac-to-flash-renumbering-events-00) Finally, I've sent draft text for the specification of the algorithm here: https://mailarchive.ietf.org/arch/msg/ipv6/KD_Vpqg0NmkVXOQntVTOMlWHWwA/ We would be super thankful if you could take a look at the draft text (i.e., https://mailarchive.ietf.org/arch/msg/ipv6/KD_Vpqg0NmkVXOQntVTOMlWHWwA/) and provide feedback/comments. If you can post/comment on the 6man wg mailing list (https://www.ietf.org/mailman/listinfo/ipv6), that´d be fabulous. But we'll appreciate your feedback off-line, on this list, etc. (that'd still be great ;-) ) Thanks in advance! Regards, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
Fwd: RFC 9288 on Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers
Hi, FYI. RFC 9288, "Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers" (available at: https://www.rfc-editor.org/rfc/rfc9288) FWIW, IMO most of the value is in the analysis of what protocols/features use what EHs, and what would break (if anything) if packets with EHs are dropped. These other two are useful for context: * RFC 9098, "Operational Implications of IPv6 Packets with Extension Headers" (https://www.rfc-editor.org/rfc/rfc9098.html) * RFC 7872, "Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World (https://www.rfc-editor.org/rfc/rfc7872.html). Thanks! Cheers, Fernando Forwarded Message Subject: RFC 9288 on Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers Date: Thu, 18 Aug 2022 16:21:47 -0700 (PDT) From: rfc-edi...@rfc-editor.org To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org CC: rfc-edi...@rfc-editor.org, drafts-update-...@iana.org, op...@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 9288 Title: Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers Author: F. Gont, W. Liu Status: Informational Stream: IETF Date: August 2022 Mailbox:fg...@si6networks.com, liushuch...@huawei.com Pages: 33 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-opsec-ipv6-eh-filtering-10.txt URL:https://www.rfc-editor.org/info/rfc9288 DOI:10.17487/RFC9288 This document analyzes the security implications of IPv6 Extension Headers and associated IPv6 options. Additionally, it discusses the operational and interoperability implications of discarding packets based on the IPv6 Extension Headers and IPv6 options they contain. Finally, it provides advice on the filtering of such IPv6 packets at transit routers for traffic not directed to them, for those cases where such filtering is deemed as necessary. This document is a product of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Scanning the Internet for Vulnerabilities
Hi, While it's possible to have a discussion on the topic, I think that the only safe bet is that, when connected to the Internet, you'll definitely be subject to scanning. I doubt there's much you want to do at a SOC about it unless it's a recurring situation involving a somewhat big traffic load -- in which case, you'd probably handle it as you'd do with a DoS attack. Scans of one sort of another happen way to often to bother (or to afford to bother, if you wish) -- for instance, just a few days ago I was setting up an imap server, and happened to find the service being scanned by censys in terms of hours. For regular mass scans, you can normally block them proactively, via a number of feeds (abuseipdb, dshield, and others), if you find them as a nuissance or don't want to show up in the scanner's results. As for targetted scans, the only safe bet is that you *will* be targetted. So... keep the windows and doors locked. And, better, check if they actually are locked regularly. Thanks, Fernando On 22/6/22 01:04, b...@theworld.com wrote: When I lock the doors etc to my home I'll often mutter "ya know, if someone is rattling my door knob I already have a big problem." I suppose when I'm home it might give me a warning if I hear it. There must be a metaphor in there somewhere. I do recall as a teen noticing that one of the closed store's on the main drag's door was unlocked late one night walking home (this was in NYC.) I saw a cop and told him and he scolded me angrily for rattling door knobs, I could be arrested for that! But verified it, looked around inside with his flashlight, and called it in. I forget how I noticed but I wasn't in the habit of rattling stores' door knobs, I think the door was just a bit ajar. There must be a metaphor in there somewhere. On June 21, 2022 at 10:01 mpal...@hezmatt.org (Matt Palmer) wrote: > On Mon, Jun 20, 2022 at 02:18:30AM +, Mel Beckman wrote: > > When researchers, or whoever, claim their scanning an altruistic service, > > I ask them if they would mind someone coming to their home and trying to > > open all the doors and windows every night. > > If there were a few hundred people with nefarious intent trying to open your > doors and windows every night, someone doing the same thing with altruistic > intent might not be such a bad thing. > > - Matt -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: Scanning the Internet for Vulnerabilities
Hi, Ronald, On 21/6/22 03:53, Ronald F. Guilmette wrote: In message <7c5f9d80-8686-07bb-b6ed-6e41fa1e1...@si6networks.com>, Fernando Gont wrote: Note: What's most usually done out there is scanning for ports, rather than for vulnerabilities. Yes, and at least some of the responses in this thread have not, I think, noted this rather important distinction. Agreed. For my part I intended to ask specifically about attitudes towards scanning for actual vulnerabilities, e.g. those that have been assigned CVE numbers. Please note that in most of these cases, "vulnerability scanning" is, for the most part, simply banner-grabbing, with some off-line comparison against CVE database -- with banner-grabbing being at times simply the result of completing the TCP three-way handshake (i.e., something that would happen anyway, unless doing non-connect() scans). IOW, you probably cannot even tell if you're being subject to a port-scan or a "vulnerability scan" of this type. Then there are other cases where the scans are way more intrusive, such as e.g. scanning for SQL injection in web applications, or., e.g., simply scanning the vulnerability by trying to exploit it. I'd probably be concerned about these sorts of "scans", but not about port-scans/banner-grabbing. Depending on who is doing it, and why, my personal feeling is that even here in 2022 this should still be viewed as being exceptionally anti-social, and worthy of calling out publicly, but I must allow for the possibility that my personal views on this may be antiquated and out of step with current prevailing norms and attitudes. Aside from what I've noted above, and without really taking a stance on whether what you not might or might not make sense, I'd probably argue that, the folks that one should probably e most concerned about would probably run the scans from VMs they probably paid with cryptocurrency. The attacks would probably be non-trivial to attribute, and if you manage to get their provider to take their VMs off-line, they would probably simply by a new one. -- not that I like it, but... "it is what it is". Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: Scanning the Internet for Vulnerabilities
Hi, Ronald, On 19/6/22 07:13, Ronald F. Guilmette wrote: I would like to solicit the opinions of network operators on the practice of scanning all of, or large chunks of the internet for known vulnerabilities. Note: What's most usually done out there is scanning for ports, rather than for vulnerabilities. That said, as noted by others, ports scans are kind of part of the echo system. A vast number of them can be blocked proactively by e.g., feeding block-lists (e.g. abuseipdb's) dynamically into your firewalls' rulesets. In earlier times, this was generally viewed as being distinctly anti-social behavior, but perhaps attitudes have changed relative to earlier eras. I would thus like to know how people feel about it now, in 2022. At the end of the day, the folks you should most likely be concerned about are the folks that won't even care about whether this is unsocial behavior. For low-volume traffic, you can probably filter it out as discussed above, and, other than the possible noise, the scans shouldn't cause harm anyway (and if e.g. an IPv6 host scan is causing you neighbor cache exhaustion problems... that's an issue you need to deal with, anyway). What's left probably falls into the DoS-like category... but is normally more targetted than sent to random networks/whole Internet. Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
IPv6 Addressing Considerations (IETF Internet-Draft)
Hi, We have published a revision of our IETF Internet-Draft "IPv6 Addressing Considerations". It is available at: https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-addressing-considerations It discusses a lot of practical considerations of IPv6 addressing, so we'd love to hear from you if there's any that we missed or that we got wrong. Abstract IPv6 addresses can differ in a number of properties, such as scope, stability, and intended usage type. This document analyzes the impact of these properties on aspects such as security, privacy, interoperability, and network operations, with the goal of providing guidance about IPv6 address usage. Additionally, it identifies challenges and gaps that currently prevent systems and applications from leveraging the increased flexibility and availability of IPv6 addresses. Thanks! Regards, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: shadowserver.org
On Mon, 2021-06-28 at 13:04 -0400, Jean St-Laurent via NANOG wrote: > What is the difference between shodan.io and shadowserver.org ? At least in theory, for the former anyone that pays for the service (or employs free credit) has access to the scan data, whereas for the later, only the responsible organization for the network prefixes get the scan results. Thanks, -- Fernando Gont Director of Information Security EdgeUno, Inc. PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
Re: shadowserver.org
On Sun, 2021-06-27 at 23:19 -0400, Scott Aldrich wrote: > Anyone have an idea how to get HE/ShadowServer,org servers to stop > attempting to penetrate the comcast drop at my house? > > Their website claims altruism.. but my logs dont support that claim. In theory (at least), your ISP asked for it. Thanks, -- Fernando Gont Director of Information Security EdgeUno, Inc. PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
Operational Implications of IPv6 Extension Headers (Fwd: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-08.txt)
Hi, folks, After almost 7+ years of working on this topic, our internet-draft entitled Operational Implications of IPv6 Packets with Extension Headers¨ ( https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-08 ), has been approved for publication as an IETF RFC. I believe it iś of value for folks working in security and/or network operations. Kudos to my co-authors for enduring the process, and to Nick Hilliard who did the last push to get this one approved. :-) Thanks! Cheers, Fernando Forwarded Message Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops- 08.txt Date: Fri, 11 Jun 2021 09:28:16 -0700 From: internet-drafts at ietf.org Reply-To: v6ops at ietf.org To: i-d-announce at ietf.org CC: v6ops at ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : Operational Implications of IPv6 Packets with Extension Headers Authors : Fernando Gont Nick Hilliard Gert Doering Warren Kumari Geoff Huston Will (Shucheng) Liu Filename: draft-ietf-v6ops-ipv6-ehs-packet-drops-08.txt Pages : 20 Date: 2021-06-11 Abstract: This document summarizes the operational implications of IPv6 extension headers specified in the IPv6 protocol specification (RFC8200), and attempts to analyze reasons why packets with IPv6 extension headers are often dropped in the public Internet. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-packet-drops/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-ehs-packet-drops-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ v6ops mailing list v6ops at ietf.org https://www.ietf.org/mailman/listinfo/v6ops -- Fernando Gont Director of Information Security EdgeUno, Inc. PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
Re: NAT devices not translating privileged ports
Hi, Jean,
On Thu, 2021-06-10 at 08:23 -0400, Jean St-Laurent wrote:
> Let's start with this example. When I click sync my clock in windows,
> this happened.
>
> On the inside or Private side
> 08:15:07.434344 IP 192.168.254.205.123 > 13.86.101.172.123: NTPv3,
> Client, length 48
> 08:15:07.473681 IP 13.86.101.172.123 > 192.168.254.205.123: NTPv3,
> Server, length 48
>
> You are indeed right that the client must use UDP port 123. Is the
> RFC saying must or should on the client SRC port? I'm not sure.
Section 9.1 ("Peer Process Variables") of [RFC5905] SAYS:
dstport: UDP port number of the client, ordinarily the NTP port
number PORT (123) assigned by the IANA. This becomes the source
port number in packets sent from this association.
That said, as noted in
https://datatracker.ietf.org/doc/html/draft-ietf-ntp-port-randomization-06#section-5
, other client implementations don't bind the local port to 123, and
hence assign an ephemeral port.
> But, on the Public, this happened.
> 08:15:07.434381 IP 192.2XX.XXX.58291 > 13.86.101.172.123: NTPv3,
> Client, length 48
> 08:15:07.473656 IP 13.86.101.172.123 > 192.2XX.XXX.58291: NTPv3,
> Server, length 48
>
> // Public ip obfuscated. I know, it indeed starts with 192.2. It's
> EBOX in Canada.
>
> What we see on the public side, is that a network device did a NAT
> translation of the SRC UDP port to 58921. My clock synced perfectly.
>
> So your goal is to find the devices that don't follow this behaviour,
> right?
> No. The goal of our I-D is that NTP clients randomize their source
> port -- there's no need for clients to use port 123, and using that
> port on the client side has negative security implications.
Thanks,
--
Fernando Gont
Director of Information Security
EdgeUno, Inc.
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
Re: NAT devices not translating privileged ports
Hi, Jean, On Thu, 2021-06-10 at 06:54 -0400, Jean St-Laurent via NANOG wrote: > Hi Fernando, > > NTP sounds simple but it could be very complex when you dig deep down > and/or get lost in details. > Here are 2 things to consider: > > 1. NTP clients can query NTP servers by using SRC UDP ports > 1024. This is indeed the case we're addressing. The NTP spec mandates srt port=123, even for client-to-server cases. > In your case, it sounds like you want to achieve NTP server to NTP > server, but you mention NTP clients behind NAT devices. Nope. We simply recommend to randomize the source port for client-to- server cases. So in the quoted section we make the case that requiring src port=123 clients doesnt really make sense: 1) if the NAT translates the port, the server won-t see src 123 anyway 2) if the NAT doesn't translate the port, you won't be able to ahve multiple NTP clients behind the same firewall. > Can you give us more details on what kind of communication you need > here? From what I understand client to server should work just fine > with any NAT devices. > > Maybe you meant multiple NTP servers behind the same NAT to external > NTP servers Please let me know if what I wrote above clarifies our intent. Thanks! Regards, -- Fernando Gont Director of Information Security EdgeUno, Inc. PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
Re: NAT devices not translating privileged ports
Hi, Bjørn, On Thu, 2021-06-10 at 12:10 +0200, Bjørn Mork wrote: > Fernando Gont via NANOG writes: > > > What has been reported to us is that some boxes do not translate > > the > > src port if it's a privileged port. > > > > IN such scenarios, NTP implementations that always use src > > port=123, > > dst port=123 might be in trouble if there are multiple NTP clients > > behind the same NAT device > > This problem used to be very common for 500/udp. Ref > https://datatracker.ietf.org/doc/html/rfc3715#section-2.3 THanks a lot for the link! -- this is indeed a good read. I'm curious if there exists something similar for UDP/123? FWIW, we have this IETF I-D on NTP port randomization: https://datatracker.ietf.org/doc/html/draft-ietf-ntp-port-randomization-06 , which has this section on the same kind of behavior, but for the NTP port: cut here 3.4. Effect on NAT devices Some NAT devices will not translate the source port of a packet when a privileged port number is employed. In networks where such NAT devices are employed, use of the NTP well-known port for the client port will essentially limit the number of hosts that may successfully employ NTP client implementations. In the case of NAT devices that will translate the source port even when a privileged port is employed, packets reaching the external realm of the NAT will not employ the NTP well-known port as the local port, since the local port will normally be translated by the NAT device possibly, but not necessarily, with a random port. cut here So I'm trying to find some reference that documents such behavior for the NTP case Thanks! Regards, -- Fernando Gont Director of Information Security EdgeUno, Inc. PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
Re: NAT devices not translating privileged ports
Hi, Jean, On Fri, 2021-06-04 at 08:36 -0400, Jean St-Laurent wrote: > I believe all devices will translate a privileged ports, but it won't > translate to the same number on the other side. It will translate to > an unprivileged port. Is it what you meant or really there are some > devices that will not translate at all a privileged port? What has been reported to us is that some boxes do not translate the src port if it's a privileged port. IN such scenarios, NTP implementations that always use src port=123, dst port=123 might be in trouble if there are multiple NTP clients behind the same NAT device Thanks! Regards, -- Fernando Gont Director of Information Security EdgeUno, Inc. PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
Re: NAT devices not translating privileged ports
Hi, Blake, Thanks a lot for your comments! In-line On Fri, 2021-06-04 at 11:13 -0500, Blake Hudson wrote: > Current gen Cisco ASA firewalls have logic so that if the connection > from a private host originated from a privileged source port, the > NAT > translation to public IP also uses an unprivileged source port (not > necessarily the same source port though). Did you actaully mean "...also uses a *privileged port*"? > > I found out that this behavior can cause issues when you have devices > on > your network that implement older DNS libraries or configs using UDP > 53 > as a source and destination port for their DNS lookups. Occasionally > the > source port gets translated to one that ISC BIND servers have in a > blocklist (chargen, echo, time, and a few others) and the query is > ignored. As I recall, this behavior is hard coded so patching and > recompiling BIND is required to work around it. > > I forget what the older ASA behavior was. It may have been to leave > the > source port unchanged through the NAT process (I think this is what > you > mean by "not translated"). In that case the client doesn't implement > source port randomization and the NAT doesn't "upgrade" the > connection > to a random source port so I don't really see it as an issue. The issue would be that if the port is not translated, and multiple systems in the internal real of the NAT try to use the same privileged port (say, 123) simultaneously, things wouldn't work. Thanks, -- Fernando Gont Director of Information Security EdgeUno, Inc. PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
NAT devices not translating privileged ports
Folks, While discussing port randomization (in the context of https://www.ietf.org/archive/id/draft-ietf-ntp-port-randomization-06.txt ), it has been raised to us that some NAT devices do not translate the source port if the source port is a privileged port (<1024). Any clues/examples of this type of NATs? Thanks! Regards, -- Fernando Gont Director of Information Security EdgeUno, Inc. PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
Fwd: IPv6 addressing: Gaps? (draft-gont-v6ops-ipv6-addressing-considerations)
Folks, FYI. The intent is to discuss this on the IETF v6ops wg list (https://www.ietf.org/mailman/listinfo/v6ops). But comments will be appreciated, regardless of the specific channel (whether on this list, off-list, etc.) Thanks! Regards, Fernando Forwarded Message Subject: IPv6 addressing: Gaps? (draft-gont-v6ops-ipv6-addressing-considerations) Date: Fri, 12 Feb 2021 18:50:48 -0300 From: Fernando Gont To: IPv6 Operations Folks, In the aforementioned document (https://tools.ietf.org/html/draft-gont-v6ops-ipv6-addressing-considerations), we have tried to do at least three things: 1) Look at what we have and try to discuss things from an architectural perspective 2) Analyze the implications of #1 (whether operations, security, privacy, etc.) 3) Find missing gaps that currently prevent us from fully leveraging IPv6 addressing. Part of what we've found as doing #3 above is that: * There are shortcomings associated with the current APIs that prevent better usage of IPv6 addresses * Multi-router/multi-prefix routing seems to be broken. RFC8028 would be a fundamental starting point in the right direction... but I believe there's more to do in this area. In that light, we'd like to hear further comments on our document. And, in particular, we're interested to hear if : * there are any operational implications of IPv6 addressing that we have missed, or, * there's anything related to IPv6 addressing that you consider to be currently broken or problematic, that is missing in our I-D. Thoughts on the current contents of the I-D are, of course, also very welcome! Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
IETF I-D: "Operational Implications of IPv6 Packets with Extension Headers" (Fwd: [v6ops] WGLC on draft-ietf-v6ops-ipv6-ehs-packet-drops)
Folks, FYI. P.S.: The relevant IETF wg list is: https://www.ietf.org/mailman/listinfo/v6ops Thanks, Fernando Forwarded Message Subject: [v6ops] WGLC on draft-ietf-v6ops-ipv6-ehs-packet-drops Date: Mon, 19 Oct 2020 12:35:34 -0700 From: Fred Baker To: IPv6 Operations I'm opening a two week WGLC on draft-ietf-v6ops-ipv6-ehs-packet-drops-01.txt. This draft started in 2015, and was set aside for a while. We took it as a working group draft in July with some additional authors, it has been recently updated in response to issues raised, and the question before the house is whether it is ready for archival state - to become an RFC. There are a number of questions: - do we agree with the language? (there are probably nits to be cleaned up) - do we agree with the concepts as stated? - do we agree with the direction the draft takes us? I think the draft could use a thorough review, and having said that, am asking for volunteers. You don't have to tell me, per se; do the review and post it to the mailing list. Two weeks gets us to November 2. ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
Re: [v6ops] Question about "Operational Implications of IPv6 Packets with Extension Headers"
Hi, Fred, On 29/7/20 05:15, Fred Baker wrote: Fernando, I asked a specific question, not "send me all of your comments". General discussion of your draft still belongs on the v6...@ietf.org list. Please don't confuse the issue. Apologies if I may have lead to confusion. I just meant to forward your request, and let folks know what the email alias for the chairs is (sometimes I get it wrong myself e.g. @ietf.org vs. @tools.ietf.org). I just didn't say "send your support comments" because I didn't want to bias the request. My apologies, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Fwd: [v6ops] Question about "Operational Implications of IPv6 Packets with Extension Headers"
Folks, FYI. You can send your comments to if you wish. Thanks, Fernando Forwarded Message Subject: [v6ops] Question about "Operational Implications of IPv6 Packets with Extension Headers" Date: Tue, 28 Jul 2020 22:55:45 -0700 From: Fred Baker Reply-To: V6Ops-Chairs To: IPv6 Operations It looks like Fernando (et al) revised this and posted draft -04 on Saturday, and there has been a flurry of discussion. I haven't been through the document or the entire thread yet, but I do observe that a number of people have comments, and several people have expressed interest in the document. Let me ask the obvious question: you we want to adopt this as a working group draft? I won't ask you to hum; whether you wish to say "yes", "no", or "abstain", please reply to this email *privately* (which is to say, to v6ops-chairs) with that word prepended on the subject line. I'll give us 48 hours, which is to say that I will evaluate and state the result Thursday evening Pacific time. https://mailarchive.ietf.org/arch/search/?qdr=a=%22draft-gont-v6ops-ipv6-ehs-packet-drops%22 https://mailarchive.ietf.org/arch/search/?qdr=a=%22Operational Implications of IPv6 Packets with Extension Headers%22 https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops "Operational Implications of IPv6 Packets with Extension Headers", Fernando Gont, Nick Hilliard, Gert Doering, Warren Kumari, Geoff Huston, 2020-07-25, ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
Operational Implications of IPv6 Packets with Extension Headers (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt)
Folks, We have posted a rev of our IETF I-D "Operational Implications of IPv6 Packets with Extension Headers". The I-D is available at: https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt Your feedback will be appreciated. Thanks! Cheers, Fernando Forwarded Message Subject: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt Date: Sat, 25 Jul 2020 22:28:50 -0700 From: internet-dra...@ietf.org To: Fernando Gont , Gert Doering , Geoff Huston , Warren Kumari , Nick Hilliard A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-v6ops-ipv6-ehs-packet-drops Revision: 04 Title: Operational Implications of IPv6 Packets with Extension Headers Document date: 2020-07-25 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt Status: https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops/ Htmlized: https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04 Htmlized: https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-ehs-packet-drops Diff: https://www.ietf.org/rfcdiff?url2=draft-gont-v6ops-ipv6-ehs-packet-drops-04 Abstract: This document summarizes the security and operational implications of IPv6 extension headers, and attempts to analyze reasons why packets with IPv6 extension headers may be dropped in the public Internet. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat
SLAAC renumbering problems (Fwd: [v6ops] draft-gont-v6ops-slaac-renum **Call for adoption**)
Folks, A while ago some of us started working on an IETF draft to document and mitigate some issues experienced by SLAAC in the face of some renumbering events. Such work has resulted in three small documents. * draft-gont-v6ops-slaac-renum (problem statement) * draft-gont-v6ops-slaac-renum (CPE recommendations) * draft-gont-6man-slaac-renum (proposed protocol updates) Two of such documents are being discussed at the v6ops wg of the IETF, where there are ongoing calls for adoption for two of them. * The "problem statement" document (https://tools.ietf.org/html/draft-gont-v6ops-slaac-renum) is being discussed at the v6ops wg of the IETF in this thread: https://mailarchive.ietf.org/arch/msg/v6ops/HmcZYGY4Lu2h7NUND3o2UiOsKXA * The "CPE recommendations" document (https://tools.ietf.org/html/draft-gont-v6ops-cpe-slaac-renum) is being discussed in the same group/list, in this thread: https://mailarchive.ietf.org/arch/msg/v6ops/yW_YdRogwMNCRvK1PKpXWgcBkmQ Feedback will be highly appreciated, particularly if on the v6ops wg mailing-list. Thanks! Cheers, Fernando Forwarded Message Subject:[v6ops] draft-gont-v6ops-slaac-renum **Call for adoption** Date: Sat, 4 Jan 2020 22:56:44 + From: Ron Bonica To: v6...@ietf.org Folks, Each week between now and IETF 107, we will review and discuss one draft with an eye towards progressing it. This week, please review and comment on draft-gont-v6ops-slaac-renum. When reviewing this draft, please indicate whether you think that V6OPS should adopt it a s a work item. Fred and Ron Juniper Business Use Only
Re: RIPE our of IPv4
On 3/12/19 17:47, Mark Andrews wrote: > > >> On 4 Dec 2019, at 02:04, Fernando Gont wrote: >> >> On 3/12/19 00:12, Mark Andrews wrote: >>> >>> >>>> On 3 Dec 2019, at 13:31, Valdis Klētnieks wrote: >>>> >>>> On Mon, 02 Dec 2019 11:04:24 -0800, Fred Baker said: >>>> >>>>>> I believe that Dmitry's point is that we will still require IPv4 >>>>>> addresses for new >>>>>> organizations deploying dual-stack >>>>> >>>>> I think I understood what you meant, but not what you said. >>>> >>>>> If someone is dual stack, they are IPv6-capable and IPv4-capable. >>>> >>>> And they're going to need v4 addresses to be v4-capable, aren't there? >>>> >>>> A new corporation that's trying to spin up dual-stack is going to need 2 >>>> address allocations, a v4 and a v6. >>> >>> Why does a new organisation need to have any global IPv4 addresses of their >>> own >>> at all? In most cases they don’t. It’s only inertia that is causing >>> people to >>> want to have their own global IPv4 addresses. >>> >>> We have IPv4 as a service which gives on demand shared IPv4 addresses. >>> Millions >>> of people reach the IPv4 Internet every day using IPv4AAS. >>> CDNs are dual stack and provide the IPv4 presence on the net. These days >>> these >>> are shared addresses. >>> VPNs run over IPv6 and they can in turn run over IPv6 in IPv4 tunnels when >>> the remote doesn’t support native IPv6. Its just another level on >>> encapsulation. >>> Email is often out sourced so you don’t need your own IPv4 addresses for >>> that. >>> Then there is in the cloud for other services, again you don’t need your >>> own IPv4 >>> addresses. >> >> Wwll, yeah.. you don't need IPv4 addresses if you are going to be using >> somebody else's networks and services. Not that you should, though… > > Why not use someone else’s IPv4 addresses? Really. What is wrong with using > someone else’s IPv4 addresses if it achieves the need? As far as I can tell > nothing. Security? Privacy? It may or may not be a concern for you. But there are implications in doing so. > Just because enterprises that established themselves in a IPv4-only world did > it one way. It doesn’t mean that enterprises establishing themselves in a > IPv4 / > IPv6 world need to follow that model. As long as you do analyze the implications and trade-offs... -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: RIPE our of IPv4
On 3/12/19 00:12, Mark Andrews wrote: > > >> On 3 Dec 2019, at 13:31, Valdis Klētnieks wrote: >> >> On Mon, 02 Dec 2019 11:04:24 -0800, Fred Baker said: >> >>>> I believe that Dmitry's point is that we will still require IPv4 addresses >>>> for new >>>> organizations deploying dual-stack >>> >>> I think I understood what you meant, but not what you said. >> >>> If someone is dual stack, they are IPv6-capable and IPv4-capable. >> >> And they're going to need v4 addresses to be v4-capable, aren't there? >> >> A new corporation that's trying to spin up dual-stack is going to need 2 >> address allocations, a v4 and a v6. > > Why does a new organisation need to have any global IPv4 addresses of their > own > at all? In most cases they don’t. It’s only inertia that is causing people > to > want to have their own global IPv4 addresses. > > We have IPv4 as a service which gives on demand shared IPv4 addresses. > Millions > of people reach the IPv4 Internet every day using IPv4AAS. > CDNs are dual stack and provide the IPv4 presence on the net. These days > these > are shared addresses. > VPNs run over IPv6 and they can in turn run over IPv6 in IPv4 tunnels when > the remote doesn’t support native IPv6. Its just another level on > encapsulation. > Email is often out sourced so you don’t need your own IPv4 addresses for that. > Then there is in the cloud for other services, again you don’t need your own > IPv4 > addresses. Wwll, yeah.. you don't need IPv4 addresses if you are going to be using somebody else's networks and services. Not that you should, though -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Fwd: SLAAC renum: Problem Statement & Operational workarounds
Folks, Your input would be very welcome. Preferably on the v6ops wg mailing-list (https://www.ietf.org/mailman/listinfo/v6ops), but also on this list or multicast to us (authors). Thanks! Forwarded Message Subject: SLAAC renum: Problem Statement & Operational workarounds Date: Wed, 23 Oct 2019 03:51:32 -0500 From: Fernando Gont To: IPv6 Operations Folks, Earlier this year there was a lot of discussion about slaac renumbering problems. Our original I-D covered everything from the problem statement to proposed protocol updates and operational workarounds. Based on the comments received while discussing this topic on this list and other forums, and in order to keep the discussion better focused on specific aspects of the problem, we have posted a v6ops-targetted document that focuses on: * The problem statement * Discussion of operational workarounds, and associated constraints The document is available at: https://tools.ietf.org/html/draft-gont-v6ops-slaac-renum We'd like to hear from the wg whether we have missed anything, whether the document is useful to the community, etc. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
IPv6 Security for IPv4 Engineers
Folks, It is often argued that IPv4 practices should be forgotten when deploying IPv6, as after all IPv6 is a different protocol! But we think years of IPv4 operational experience should be leveraged as much as possible. So we are publishing IPv6 Security for IPv4 Engineers as a roadmap to IPv6 security that is specifically aimed at IPv4 engineers and operators. Rather than describing IPv6 in an isolated manner, it aims to re-use as much of the existing IPv4 knowledge and experience as possible, by highlighting the security issues that affect both protocols in the same manner, and those that are new or different for the IPv6 protocol suite. Additionally, it discusses the security implications arising from the co-existence of the IPv6 and IPv4 protocols. The document is available at: https://www.internetsociety.org/blog/2019/03/ipv6-security-for-ipv4-engineers/ Comments are welcome. And if you think we've missed something or the like, please drop me en email -- the document can always be revised. P.S.: If you haven't taken a look at it (yet), we have also published the "IPv6 Security Frequently Asked Questions (FAQ)" at: https://www.internetsociety.org/blog/2019/02/ipv6-security-faq Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: SLAAC in renumbering events
Hi, Bill, Thanks for the feedback! In-line On 10/3/19 13:54, William Herrin wrote: > > > On Fri, Mar 8, 2019 at 3:32 AM Fernando Gont <mailto:fg...@si6networks.com>> wrote: > > If you follow the 6man working group of the IETF you may have seen a > bunch of emails on this topic, on a thread resulting from an IETF > Internet-Draft we published with Jan Žorž about "Reaction of Stateless > Address Autoconfiguration (SLAAC) to Renumbering Events" (Available at: > > https://github.com/fgont/draft-slaac-renum/raw/master/draft-gont-6man-slaac-renum-02.txt > ) > > > Hi Fernando, > > I'm a little confused here. I can certainly see why the default timeout > of 30 days is a problem, but doesn't the host lose the route from the RA > sooner? Which route? Configuration of addresses is mostly a different business than acquiring routes. SO, in the typical scenario where the CPE crashes and reboots, hosts will even have a default route -- advertised by the router that crashed and rebooted. If you are referring to the "on-link" route -- i.e., the route introduced because the Prefix Information Option had the "L" bit set -- then I don't think there's anything in the standard to actually grabage-collect such routes. > Why would an IPv6 host originate connections from an address for > which it has no corresponding route? Isn't that broken source address > selection? Please see above. The mechanism we specified in Section 5.1.3 of our draft tries to do exactly that: Try to detect when a previously-advertised prefix has become stale... and when it's inferred to be stale, just remove all the corresponding information. Regarding fixing this issue with source address selection: some have suggested that his should be addressed in source address selection. However, there are a number of problems with this. If you prioritize addresses from the prefix that was last advertised, then source addresses are guaranteed to flap -- and in the cause of multi-prefix networks, this would become a troubleshooting nightmare. Secondly, if you don't remove the on-link route for the stale-prefix, then packets meant to the new "owners" of that prefix will be assumed to be on-link, and hence communication will fail. This should probably be an indication that the solution is not to avoid using the stale information, but rather discarding it in a timelier manner. Please do let me know if I've missed anything. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
SLAAC in renumbering events
Folks, If you follow the 6man working group of the IETF you may have seen a bunch of emails on this topic, on a thread resulting from an IETF Internet-Draft we published with Jan Žorž about "Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering Events" (Available at: https://github.com/fgont/draft-slaac-renum/raw/master/draft-gont-6man-slaac-renum-02.txt ) Short version of story: There are a number of scenarios where SLAAC hosts may end up using stale configuration information. For example, a typical IPv6 deployment scenario is that in which a CPE router requests an IPv6 prefix to an ISP via DHCPv6-PD, and advertises a sub-prefix of of the leased prefix on the LAN-side, via SLAAC. In such scenarios, if the CPE router crashes and reboots, it may loose all information about the previously-leased prefix. Upon reboot, the CPE router may be leased a new prefix that will result in a new sub-prefix being advertised on the LAN-side of the CPE router. As a result, hosts will normally configure addresses for the newly-advertised prefix, but will normally also keep (and use) the previously-configured (and now stale!) IPv6 addresses, leading to interoperability problems. The RIPE-690 BCOP document had originally tried to address this problem by recommending operators to lease stable IPv6 prefixes to CPE routers. However, for a variety of reasons ISP may not be able (or may not want) to lease stable prefixes, and may instead lease dynamic prefixes. Most of the voices on the 6man wg mailing-list fell into one of the following camps: * "ISPs should be leasing stable prefixes -- if they don't, they are asking for trouble!" * "CPE routers should record leased prefixes on stable storage, such that they can 'deprecate' such prefixes upon restart -- if they don't, they are asking for trouble!" * "No matter whose fault is this (if there is any single party to blame in the first place), we should improve the robustness of IPv6 deployments" Our Internet-Draft tries to improve the current state of affairs via the following improvements: * Allow hosts to gracefully recover from stale network configuration information -- i.e., detect and discard stale network configuration information * Have SLAAC routers employ more appropriate timers, such that information is phased-out in a timelier manner -- unless it is actively refreshed by Router Advertisement messages * Specify the interaction between DHCPv6-PD and SLAAC -- which was rather under-specified * Require CPE routers to store leased prefixes on stable storage, and deprecate stale prefixes (if necessary) upon restart We are looking forward to more input on the document (or any comments on the issue being discussed), particularly from operators. So feel free to send your comments on/off list as you prefer Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: IPv6 Security Frequently Asked Questions (FAQ)
Hello, Mark, Thanks for your feedback! Please see in-line On 8/3/19 04:10, Mark Andrews wrote: > "Generation of IPv6 fragments in response to ICMPv6 PTB messages has been > deprecated in the revised IPv6 specification" > > IS INCORRECT > > generation of fragments is “discouraged". Discouraged and deprecated mean > different thing. There is a writeo here. The text should have said "generation of IPv6 atomic fragments", or, "Generation of IPv6 fragments in response to ICMPv6 PTB messages advertising an MTU smaller than 1280" The whole section refers to "atomic fragments" which might be generated even for protocols that are not supposed to employ fragmentation. I will clarify this in the next rev. > > However, the use of such >fragmentation is discouraged in any application that is able to >adjust its packets to fit the measured path MTU (i.e., down to 1280 >octets). > > the whole of 4.4 is very badly worded and states things as fact which don’t > appear in RFC’s at all. Please let me know if, considering the writeo I referred to above, you still feel the same. > > The adding of a fragmentation header for PTB <1280 has gone. Fragmentation > down to 1280 is still supposed to happen in response to a PTB. Packets still > have to flow through paths that narrow down to 1280. Agreed. This section is referred to this scenario: Say two nodes only mean to employ a TCP-based application (say two BGP peers). Say they filter fragments directed to them, since the TCP connections will avoid fragmentation. In such cases, what would seem as a "safe practice" may be not: if the involved systems employ a legacy IPv6 implementation, then an attacker can trigger the generation of IPv6 fragments (even for TCP conenctions) by spoofing an ICMPv6 PTB claiming an MTU < 1280. This is what this section is about: If you are going to drop fragments, make sure you also take care of ICMPv6 PTBs, since they may trigger fragmentation even for protocols that you'd assume would never emply fragmentation. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
IPv6 Security Frequently Asked Questions (FAQ)
Folks, The Internet Society has posted the "IPv6 Security Frequently Asked Questions (FAQ)" I authored. The document is available (in HTML, and also easy-to-print PDF) at: https://www.internetsociety.org/deploy360/ipv6/security/faq/ If you think there are other questions that should be added, or have comments on the answers, please do let me know -- the document can eventually be revised. Thanks! Cheers, -- -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: WIndows Updates Fail Via IPv6 - Update!
On 6/3/19 03:29, Mark Andrews wrote: > > >> On 6 Mar 2019, at 3:37 pm, Fernando Gont wrote: >> >> On 6/3/19 01:09, Mark Andrews wrote: >>> >>> >>>> On 6 Mar 2019, at 1:30 pm, Fernando Gont wrote: >>>> >>>> On 3/3/19 18:04, Mark Andrews wrote: >>>>> There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB >>>>> getting >>>>> back to the TCP servers. There are also IDIOTS that deploy load >>>>> balancers that >>>>> DO NOT LOOK INSIDE ICMP messages for redirecting ICMP messages to the >>>>> correct >>>>> back end. There are also IDOITS that rate limit PTB generation to >>>>> ridiculously >>>>> low rates. One should be able to generate PTB at line rate. >>>>> >>>>> Everyone that has configured mss-fix-up has contributed to >>>>> misunderstanding that >>>>> you can block ICMP. It is time we had a flag day to REMOVE mss-fix-up >>>>> from all >>>>> the boxes you control. We need to get PTB working and unfortunately that >>>>> means >>>>> that we need to stop pandering to admins who don’t know how IP is >>>>> supposed to >>>>> work. ICMP is NOT optional. >>>> >>>> It would seem IETF's intention is to actually move away from >>>> ICMPv6-based PMTUD, to the extent that is possible. (RFC4821). >>> >>> Which is not a reason to not fix broken equipment and misconfigured >>> firewalls. >>> The workarounds are basically there because people deploy broken equipment. >> >> Agreed. That said, it wasn't solved in 30+ years of IPv4. Do you have >> hopes it will be different with IPv6? > > Make a big enough stink and it will get fixed. People just don’t make enough > of > a stink. Use social media. None of the companies with broken firewalls > really > want their idiotic practices pointed out in public. Start doing so every time > you see it #STUPIDFIREWALL. At times, it's fw defaults. Other times, it is admin policies. RFC4821 seems to signal that the IETF has given up in making ICMP-based PMTUD work, and aims at a (mostly) ICMP-free PMTUD. Essentially, when brokenness is widespread, you have to come-up with workarounds. And when workarounds are sufficiently widespread, there's less of an incentive to fix the original issue. Other times, there's a disconnect between with protocol standards, products, and operational requirements. That's the case of IPv6 EHs. This is their usability on the public Internet: RFC 7872. And these are some of the reasons why you get the numbers in RFC 7872: https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops Cheers, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: WIndows Updates Fail Via IPv6 - Update!
On 6/3/19 01:09, Mark Andrews wrote: > > >> On 6 Mar 2019, at 1:30 pm, Fernando Gont wrote: >> >> On 3/3/19 18:04, Mark Andrews wrote: >>> There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB >>> getting >>> back to the TCP servers. There are also IDIOTS that deploy load balancers >>> that >>> DO NOT LOOK INSIDE ICMP messages for redirecting ICMP messages to the >>> correct >>> back end. There are also IDOITS that rate limit PTB generation to >>> ridiculously >>> low rates. One should be able to generate PTB at line rate. >>> >>> Everyone that has configured mss-fix-up has contributed to misunderstanding >>> that >>> you can block ICMP. It is time we had a flag day to REMOVE mss-fix-up from >>> all >>> the boxes you control. We need to get PTB working and unfortunately that >>> means >>> that we need to stop pandering to admins who don’t know how IP is supposed >>> to >>> work. ICMP is NOT optional. >> >> It would seem IETF's intention is to actually move away from >> ICMPv6-based PMTUD, to the extent that is possible. (RFC4821). > > Which is not a reason to not fix broken equipment and misconfigured firewalls. > The workarounds are basically there because people deploy broken equipment. Agreed. That said, it wasn't solved in 30+ years of IPv4. Do you have hopes it will be different with IPv6? Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms
On 5/3/19 03:26, Mark Andrews wrote: > > >> On 5 Mar 2019, at 5:18 pm, Mark Tinka wrote: >> >> >> >> On 5/Mar/19 00:25, Mark Andrews wrote: >> >>> >>> Then Cloudflare should negotiate MSS’s that don’t generate PTB’s if >>> they have installed broken ECMP devices. The simplest way to do that >>> is to set the interface MTUs to 1280 on all the servers. Why should >>> the rest of the world have to put up with their inability to purchase >>> devices that work with RFC compliant data streams. >> >> I've had this issue with cdnjs.cloudflare.com for the longest time at my >> house. But as some of you may recall, my little unwanted TCP MSS hack >> for IPv6 last weekend fixed that issue for me. >> >> Not ideal, and I so wish IPv6 would work as designed, but… > > It does work as designed except when crap middleware is added. ECMP > should be using the flow label with IPv6. It has the advantage that > it works for non-0-offset fragments as well as 0-offset fragments and > also works for transports other than TCP and UDP. This isn’t a protocol > failure. It is shitty implementations. Not to play devil's advocate but the IETF fot to publish a spec for ECMP use of Flow Labels only a few years ago. For quite a while, they were unasable... and might still be, for some implementations. -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: WIndows Updates Fail Via IPv6 - Update!
On 3/3/19 20:16, Mark Andrews wrote: > > >> On 4 Mar 2019, at 9:33 am, Stephen Satchell wrote: >> >> On 3/3/19 1:04 PM, Mark Andrews wrote: >>> There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB >>> getting >>> back to the TCP servers. >> >> For those of us who are in the dark, "PTB" appears to refer to "Packet >> Too Big" responses in ICMPv6. >> >> Yes, some admins don't have fine-enough grain tools to block or throttle >> specific types of ICMP, but that's the fault of the vendors, not the admins. > > No, it is the fault of the admins. They should be making it part of the > purchasing > decision if they want to filter ICMP. It’s not like selective filtering is a > new idea. > It is well over 20 years old at this stage. The amount of +20 year old > equipment on the > net is minimal. > > That said modern OS’s don’t need other equipment to “protect" them from ICMP > of any form. > These news don't help in that direction: https://www.theregister.co.uk/2016/06/02/cisco_warns_of_ipv6_dos_vulnerability/ (I'm not complaining about the news, but about the bugs, if you wish) -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: WIndows Updates Fail Via IPv6 - Update!
On 3/3/19 18:04, Mark Andrews wrote: > There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB > getting > back to the TCP servers. There are also IDIOTS that deploy load balancers > that > DO NOT LOOK INSIDE ICMP messages for redirecting ICMP messages to the correct > back end. There are also IDOITS that rate limit PTB generation to > ridiculously > low rates. One should be able to generate PTB at line rate. > > Everyone that has configured mss-fix-up has contributed to misunderstanding > that > you can block ICMP. It is time we had a flag day to REMOVE mss-fix-up from > all > the boxes you control. We need to get PTB working and unfortunately that > means > that we need to stop pandering to admins who don’t know how IP is supposed to > work. ICMP is NOT optional. It would seem IETF's intention is to actually move away from ICMPv6-based PMTUD, to the extent that is possible. (RFC4821). Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: WIndows Updates Fail Via IPv6 - Update!
On 3/3/19 16:57, Jeroen Massar wrote: > On 2019-03-03 20:13, Mark Tinka wrote: >> >> >> On 3/Mar/19 18:05, Jeroen Massar wrote: >> >>> IPv6 requires a minimum MTU of 1280. >>> >>> If you cannot transport it, then the transport (the tunnel in this case) >>> needs to handle the fragmentation of packets of 1280 down to whatever does >>> fit in the tunnel. >> >> As you know, IPv6 does not support fragmentation in transit. So that's >> not an option. > > The transport (tunnel) CAN support that kind of fragmentation. Still, that's certainly not panacea. See: https://tools.ietf.org/html/rfc7872 -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms
On 27/2/19 07:01, Jean-Daniel Pauget wrote: > hello, > > I confess using IPv6 behind a 6in4 tunnel because the "Business-Class" > service > of the concerned operator doesn't handle IPv6 yet. > > as such, I realised that, as far as I can figure, ICMPv6 packet "too-big" > (rfc 4443) > seem to be ignored or filtered at ~60% of ClouFlare's http farms > > as a result, random sites such as http://nanog.org/ or > https://www.ansible.com/ > are badly reachable whenever small mtu are involved ... > > support@cloudflare answered me that because I'm not the owner of > concerned site, > and because of security reasons, they wouldn't investigate further. > > are there security concerns with ICMP-too-big ? Please see: https://tools.ietf.org/html/rfc5927 and also: https://tools.ietf.org/html/rfc8021 Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: UPnP/IPv6 support in home routers?
Hello, Valdis, On 12/11/2017 10:44 AM, valdis.kletni...@vt.edu wrote: > On Mon, 11 Dec 2017 09:23:11 -0300, Fernando Gont said: > >> Anyone can comment on the UPnP support for IPv6 in home routers? >> >> Those that I have checked have UPnP support for IPv4, but not for IPv6 >> -- even when the home router does otherwise support IPv6. > > Well, there's a bit of a problem there. > > Near as I can tell, to get IPv6 support you need to use IGDv2. > > Unfortunately, if you want your Xbox or Playstation to be able > to work, you need to be using IGDv1. Could you elaborate on why IGDv1 is needed? (why things break with IGDv2) > Guess what almost everybody chooses to do? > > (Been there, done that - had to rebuild miniupnpd for OpenWRT/Lede > because it built with v2 by default) I see your point. Now, how are apps that currently rely on punching holes into the NAT or filtering device to work in a v6-only scenario? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
UPnP/IPv6 support in home routers?
Folks, Anyone can comment on the UPnP support for IPv6 in home routers? Those that I have checked have UPnP support for IPv4, but not for IPv6 -- even when the home router does otherwise support IPv6. Looking at UPnP itself, it seems to allow opening holes at the IGD, but on a fully-specified (local ip, local port, remote ip, remote port) basis, which kind of sucks -- as one would want to be able to whitelist all ports for a given IP address, or at least (local ip, local port). Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: IPv6 first hop security on a budget?
On 05/05/2017 08:27 PM, Joel Whitehouse wrote: > What's a good budget option for switching a small lab or office ipv6 > with RA Guard, DHCP6 snooping, and ICMP6 snooping? > If you do deploy this, please take a look at the issues discussed in RFC7113. Similar stuff is likely to apply to DHCPv6 snooping et al. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Fwd: New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt)
Folks, FYI: <https://www.ietf.org/internet-drafts/draft-gont-v6ops-host-configuration-00.txt> The document is being discussed in the v6ops wg of the IETF. Looks like IETF is not going to do anything about it. But check the corresponding thread at: <https://goo.gl/JZO031>, since you'll have at least a few #facepalm moments. Thanks, Fernando Forwarded Message Subject: New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) Date: Tue, 28 Feb 2017 05:13:25 -0300 From: Fernando Gont <fg...@si6networks.com> To: IPv6 Operations <v6...@ietf.org> Folks, Based on a recent discussion regarding the problem of conveying DNS information in IPv6 networks, we have submitted this short I-D, in the hopes of getting the aforementioned problem solved. Your feedback will be appreciated. Thanks! Fernando (and co-autors) Forwarded Message Subject: New Version Notification for draft-gont-v6ops-host-configuration-00.txt Date: Mon, 27 Feb 2017 23:51:03 -0800 From: internet-dra...@ietf.org To: Fernando Gont <fg...@si6networks.com>, Gert Doering <g...@space.net>, Madelen Garcia Corbo <madelen.garci...@gmail.com>, Madelen Corbo <madelen.garci...@gmail.com>, Guillermo Gont <gg...@si6networks.com> A new version of I-D, draft-gont-v6ops-host-configuration-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-v6ops-host-configuration Revision: 00 Title: On the Dynamic/Automatic Configuration of IPv6 Hosts Document date: 2017-02-27 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-gont-v6ops-host-configuration-00.txt Status: https://datatracker.ietf.org/doc/draft-gont-v6ops-host-configuration/ Htmlized: https://tools.ietf.org/html/draft-gont-v6ops-host-configuration-00 Abstract: IPv6 has two different mechanisms for dynamic/automatic host configuration: SLAAC and DHCPv6. These two mechanisms allow for the configuration of IPv6 addresses and a number of network parameters. While there is overlap in the parameters that can be configured via these two protocols, different implementations support only subsets of such parameters with either mechanism, or have no support for DHCPv6 at all. This document analyzes a problem that arises from this situation, and mandates that all host implementations support RFC 6105 (DNS options for SLAAC) and the stateless DHCPv6 functionality in RFC 3315. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat
Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)
On 01/12/2017 11:14 PM, Mark Andrews wrote: > In message >
Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)
On 01/12/2017 11:07 PM, Mark Andrews wrote: > In message > <cag6teat9eodf-oihh0vow25gfc-p__p+no9ykmycbsuqhop...@mail.gmail.com> > , Fernando Gont writes: >> El 12/1/2017 16:28, "Mark Andrews" <ma...@isc.org> escribi=C3=B3: >> >>> In message <11ff128d-2fba-7c26-4a9c-5611433d8...@si6networks.com>, Fernando >>> Gont writes: >>>> Hi, Saku, >>>> >>>> On 01/12/2017 11:43 AM, Saku Ytti wrote: >>>>> On 12 January 2017 at 13:19, Fernando Gont <fg...@si6networks.com> >>> wrote: >>>>> >>>>> Hey, >>>>> >>>>>> I'm curious about whether folks are normally filtering ICMPv6 PTB<1280 >>>>>> and/or IPv6 fragments targeted to BGP routers (off-list datapoints are >>>>>> welcome). >>>>> >>>>> Generally may be understood differently by different people. If >>>>> generally is defined as single most typical behaviour/configuration, >>>>> then generally people don't protect their infrastructure in any way at >>>>> all, but fully rely vendor doing something reasonable. >>>>> >>>>> I would argue BCP is to have 'strict' CoPP. Where you specifically >>>>> allow what you must then have ultimate rule to deny everything. If you >>>>> have such CoPP, then this attack won't work, as you clearly didn't >>>>> allow any fragments at all (as you didn't expect to receive BGP >>>>> fragments from your neighbours). >>>> >>>> That's the point: If you don't allow fragments, but your peer honors >>>> ICMPv6 PTB<1280, then dropping fragments creates the attack vector. >>> >>> And fragments are a *normal* part of IP for both IPv4 and IPv6. >>> This obsession with dropping all fragments (and yes it is a obsession) >>> is breaking the internet. >> >> Vendors got the frag reassembly code wrong so many times , that I >> understand the folk that decides to drop them if deemed unnecessary. > > Most of them literally decades ago. Disagree. Microsoft "reinvented" ping-o-death in IPv6, there have been several one-packet crashes disclosed for Cisco's (an the list continues). > 20+ years ago while you waited > for you vendor to fix the bug it made some sense as most of your > boxes were vulnerable. It was a new threat back then. It doesn't > make sense today. Let's face it: The quality of many IPv6 implementations is that of IPv4 implementations in the '90s. Sad, but true. > Packet bigger than 1500 are a part of todays internet. Have a look > a the stats for dropped fragments. They aren't for the most part > attack traffic. Its legitmate reply traffic that has been requested. I don't disagree with you wrt the need for fragmentation in some scenarios. I'm just saying that when you only employ TCP-based services, it may make sense to drop fragments targeted *at you*. Fragmentation is only needed for non-TCP services. and if your system does not use non-tcp services, it may be a sensible thing to drop fragments targetted at you. Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)
El 12/1/2017 16:32, "Saku Ytti" <s...@ytti.fi> escribió: On 12 January 2017 at 17:02, Fernando Gont <fg...@si6networks.com> wrote: > That's the point: If you don't allow fragments, but your peer honors > ICMPv6 PTB<1280, then dropping fragments creates the attack vector. Thanks. I think I got it now. Best I can offer is that B could try to verify the embedded original packet? Hopefully attacker won't have access to that information. An if attacker has access to that information, they may as well do TCP RST, right? Didn't we have same issues in IPv4 with ICMP unreachable and frag neeeded, DF set? And vendors implemented more verification if the ICMP message should be accepted. Yes and no. 1) there was no way in v4 to trigger use of fragmentation for an arbitrary flow. 2) in v4 you were guaranteed to get the IP+TCP header in the ICMP payload. In ipv6, you aren't (think ipv6 EHs) Thanks, Fernando
Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)
El 12/1/2017 16:28, "Mark Andrews" <ma...@isc.org> escribió: In message <11ff128d-2fba-7c26-4a9c-5611433d8...@si6networks.com>, Fernando Gon t writes: > Hi, Saku, > > On 01/12/2017 11:43 AM, Saku Ytti wrote: > > On 12 January 2017 at 13:19, Fernando Gont <fg...@si6networks.com> wrote: > > > > Hey, > > > >> I'm curious about whether folks are normally filtering ICMPv6 PTB<1280 > >> and/or IPv6 fragments targeted to BGP routers (off-list datapoints are > >> welcome). > > > > Generally may be understood differently by different people. If > > generally is defined as single most typical behaviour/configuration, > > then generally people don't protect their infrastructure in any way at > > all, but fully rely vendor doing something reasonable. > > > > I would argue BCP is to have 'strict' CoPP. Where you specifically > > allow what you must then have ultimate rule to deny everything. If you > > have such CoPP, then this attack won't work, as you clearly didn't > > allow any fragments at all (as you didn't expect to receive BGP > > fragments from your neighbours). > > That's the point: If you don't allow fragments, but your peer honors > ICMPv6 PTB<1280, then dropping fragments creates the attack vector. And fragments are a *normal* part of IP for both IPv4 and IPv6. This obsession with dropping all fragments (and yes it is a obsession) is breaking the internet. Vendors got the frag reassembly code wrong so many times , that I understand the folk that decides to drop them if deemed unnecessary. Even if you don't want to allow all fragments through you can allow fragments between the two endpoints of a "active" connection. At times folks want to get rid of fragments directed to them, rather than those going *through* them. You can apply port filters to the offset 0 fragments. If that fragment doesn't have enough headers to be able to filter then drop it. If your firewall is incapable of doing this then find a better firewall as the current one is a piece of garbage and should be in the recycle bin. Which DoS is the bigger issue? Firewalls dropping fragments or reassembly buffers being exhausted? If there is no way for an attacker to trigger the use of fragmentation, and you don't need fragments (e.g. only tcp-based services), from a security pov you're certainly better off dropping frags that are thrown at you. Not that I like it, but Thanks, Fernando
Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)
Many (most?) Implementations don't even check the embedded port numbers...do tye attacker does not even need to guess the client port. besides, becaude of ipv6 ehs, you're not really guaranteed to receive e.g. the tcp header in the embedded payload (the embedded payload could easily be fixed ipv6 header + ehs). Cheers, Fernando El 12/1/2017 16:32, "Saku Ytti" <s...@ytti.fi> escribió: > On 12 January 2017 at 17:02, Fernando Gont <fg...@si6networks.com> wrote: > > That's the point: If you don't allow fragments, but your peer honors > > ICMPv6 PTB<1280, then dropping fragments creates the attack vector. > > Thanks. I think I got it now. Best I can offer is that B could try to > verify the embedded original packet? Hopefully attacker won't have > access to that information. An if attacker has access to that > information, they may as well do TCP RST, right? > > Didn't we have same issues in IPv4 with ICMP unreachable and frag > neeeded, DF set? And vendors implemented more verification if the ICMP > message should be accepted. > > -- > ++ytti >
Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)
Hi, Saku, On 01/12/2017 11:43 AM, Saku Ytti wrote: > On 12 January 2017 at 13:19, Fernando Gont <fg...@si6networks.com> wrote: > > Hey, > >> I'm curious about whether folks are normally filtering ICMPv6 PTB<1280 >> and/or IPv6 fragments targeted to BGP routers (off-list datapoints are >> welcome). > > Generally may be understood differently by different people. If > generally is defined as single most typical behaviour/configuration, > then generally people don't protect their infrastructure in any way at > all, but fully rely vendor doing something reasonable. > > I would argue BCP is to have 'strict' CoPP. Where you specifically > allow what you must then have ultimate rule to deny everything. If you > have such CoPP, then this attack won't work, as you clearly didn't > allow any fragments at all (as you didn't expect to receive BGP > fragments from your neighbours). That's the point: If you don't allow fragments, but your peer honors ICMPv6 PTB<1280, then dropping fragments creates the attack vector. -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)
Folks, I'm curious about whether folks are normally filtering ICMPv6 PTB<1280 and/or IPv6 fragments targeted to BGP routers (off-list datapoints are welcome). In any case, you mind find it worth reading to check if you're affected (from Section 2 of recently-published RFC8021): cut here The security implications of IP fragmentation have been discussed at length in [RFC6274] and [RFC7739]. An attacker can leverage the generation of IPv6 atomic fragments to trigger the use of fragmentation in an arbitrary IPv6 flow (in scenarios in which actual fragmentation of packets is not needed) and can subsequently perform any type of fragmentation-based attack against legacy IPv6 nodes that do not implement [RFC6946]. That is, employing fragmentation where not actually needed allows for fragmentation-based attack vectors to be employed, unnecessarily. We note that, unfortunately, even nodes that already implement [RFC6946] can be subject to DoS attacks as a result of the generation of IPv6 atomic fragments. Let us assume that Host A is communicating with Host B and that, as a result of the widespread dropping of IPv6 packets that contain extension headers (including fragmentation) [RFC7872], some intermediate node filters fragments between Host B and Host A. If an attacker sends a forged ICMPv6 PTB error message to Host B, reporting an MTU smaller than 1280, this will trigger the generation of IPv6 atomic fragments from that moment on (as required by [RFC2460]). When Host B starts sending IPv6 atomic fragments (in response to the received ICMPv6 PTB error message), these packets will be dropped, since we previously noted that IPv6 packets with extension headers were being dropped between Host B and Host A. Thus, this situation will result in a DoS scenario. Another possible scenario is that in which two BGP peers are employing IPv6 transport and they implement Access Control Lists (ACLs) to drop IPv6 fragments (to avoid control-plane attacks). If the aforementioned BGP peers drop IPv6 fragments but still honor received ICMPv6 PTB error messages, an attacker could easily attack the corresponding peering session by simply sending an ICMPv6 PTB message with a reported MTU smaller than 1280 bytes. Once the attack packet has been sent, the aforementioned routers will themselves be the ones dropping their own traffic. cut here Is this something waiting to be exploited? Am I missing something? Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Fwd: [v6ops] RFC 7872 on Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World
FYI Forwarded Message Subject: [v6ops] RFC 7872 on Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World Date: Tue, 21 Jun 2016 16:57:35 -0700 (PDT) From: rfc-edi...@rfc-editor.org To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org CC: v6...@ietf.org, rfc-edi...@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 7872 Title: Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World Author: F. Gont, J. Linkova, T. Chown, W. Liu Status: Informational Stream: IETF Date: June 2016 Mailbox:fg...@si6networks.com, fu...@google.com, tim.ch...@jisc.ac.uk, liushuch...@huawei.com Pages: 15 Characters: 30924 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-v6ops-ipv6-ehs-in-real-world-02.txt URL:https://www.rfc-editor.org/info/rfc7872 DOI:http://dx.doi.org/10.17487/RFC7872 This document presents real-world data regarding the extent to which packets with IPv6 Extension Headers (EHs) are dropped in the Internet (as originally measured in August 2014 and later in June 2015, with similar results) and where in the network such dropping occurs. The aforementioned results serve as a problem statement that is expected to trigger operational advice on the filtering of IPv6 packets carrying IPv6 EHs so that the situation improves over time. This document also explains how the results were obtained, such that the corresponding measurements can be reproduced by other members of the community and repeated over time to observe changes in the handling of packets with IPv6 EHs. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
IETF RFC 7707: Network Reconnaissance in IPv6 Networks
Folks, Tim Chown and me have published RFC7707 on "Network Reconnaissance in IPv6 Networks". The RFC is available at: <https://www.rfc-editor.org/rfc/rfc7707.txt>. You can find some context for this RFC here: <http://blog.si6networks.com/2016/03/the-ietf-has-just-published-rfc-7707_12.html> Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
IETF I-D: "Operational Implications of IPv6 Packets with Extension Headers"
Folks, We have revised our IETF I-D "Operational Implications of IPv6 Packets with Extension Headers". The I-D is available at: <https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-01> Your feedback will be appreciated. If possible, please send your comments to: <draft-gont-v6ops-ipv6-ehs-packet-dr...@tools.ietf.org> and CC <v6...@ietf.org>. P.S.: You can find a number of pointers to articles and other related work on this topic here: <http://blog.si6networks.com/2015/12/the-controversial-ipv6-extension-headers.html> Thanks! Best regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: Seeking IPv6 Security Resources
Hi, Chris, On 11/25/2014 05:32 PM, Chris Grundemann wrote: Hail NANOG! I am looking for IPv6 security resources to add to: http://www.internetsociety.org/deploy360/ipv6/security/ This is stuff that I've authored or that I've been involved in: Tools * (Open Source) IPv6 Security Toolkit: http://www.si6networks.com/tools/ipv6toolkit/index.html Articles This site links all the articles that I've written so far: http://www.si6networks.com/publications/articles.html. They tend to cover stuff that I've covered in IETF RFCs, but in a more synthetic and human-readable way. Note while stuffed with some adds (Techtarget has to make money somehow), the full content of the articles is online, without the requirement of creating an account or anything just scroll down. IETF RFCs Internet Drafts Most of what I've published at the IETF in the last few years is IPv6-securty related. Please check: http://datatracker.ietf.org/doc/search/?name=rfcs=onactivedrafts=onolddrafts=onsort=by=authorauthor=Gont Of particular interest would be: * draft-ietf-6man-ipv6-address-generation-privacy * draft-ietf-opsec-ipv6-host-scanning * RFC6980 * RFC7112 * RFC7113 * RFC7123 * RFC7217 * RFC7359 Presentations (slides videos) * Slides: http://www.si6networks.com/presentations/index.html (More to be uploaded soon... please re-check in a week or so) * Videos: https://www.youtube.com/user/SI6Networks On-line communities * IPv6 Hackers mailing-list: http://lists.si6networks.com/listinfo/ipv6hackers/ * IPv6 Hackers web site: http://www.ipv6hackers.org This site includes the slideware (and videos) of the first (and so far only) IPv6 hackers meeting in Berlin 2013. Thanks! Best regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
IPv6 Extension Headers in the Real World
Folks, Earlier in September we published a revision of our I-D IPv6 Extension Headers in the Real World (https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-world). At this point in time, we're interested in knowing whether our I-D is of value for the IPv6 ops community, such that we can decide whether to continue working/improving it. Additionally, if there's anything you think we've missed in the document, we'd like to hear from you. Overall, our I-D is meant to provide a reality-check with respect to the issues surrounding IPv6 Extension Headers and their use on the public Internet. More specifically, its goals are: 1) Provide data regarding support of IPv6 EHs in the real world. This is interesting data to refer people to (e.g., folks developing protocols) regarding the extent to which IPv6 EHs are usable on the public Internet (at least with web, mail, and name servers). 2) Summarize the issues associated with IPv6 EHs (performance, security, etc.) This is of use for folks concerned with the issues surrounding IPv6 EHs, and covers practical issues. 3) Summarizes the implications of the aforementioned filtering. For example, if you're designing a protocol that is meant to work on the public Internet, you may want to provide some fall-back mechanism that does not employ IPv6 EHs. Yet another of the implications is the security issue that has been discussed on-list: if e.g. IPv6 fragments are dropped and you can be tricked into generating them, you may be subject to a DoS attack. 4) Flag possible further work Here we try to flag areas where the further work may be needed, such as adding fall-back mechanisms to some existing protocols, or avoiding the use of IPv6 EHs where possible. Thanks! Best regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Fwd: DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
Folks, FYI -- currently being discussed on v6...@ietf.org Cheers, Fernando Forwarded Message Subject: DoS attacks (ICMPv6-based) resulting from IPv6 EH drops Date: Tue, 19 Aug 2014 09:00:15 -0300 From: Fernando Gont fg...@si6networks.com To: IPv6 Operations v6...@ietf.org CC: 'op...@ietf.org' op...@ietf.org Folks, Ten days ago or so we published this I-D: http://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-in-real-world-00.txt Section 5.2 of the I-D discusses a possible attack vector based on a combination of forged ICMPv6 PTB messages and IPv6 frag drops by operators, along with proposed countermeasures -- on which we'd like to hear your comments. Since Section 5.2 is in the draft, let me offer a more informal and practical explanation: 1) It is known that filtering of packets containing IPv6 Extension Headers (including the Fragment Header) is widespread (see our I-D above) 2) Let us assume that Host A is communicating with Server B, and that some node filters fragments between Host A and Server B. 3) An attacker sends a spoofed ICMPv6 PTB to server B, with a Next Hop MTU1280), in the hopes of eliciting atomic fragments (see http://tools.ietf.org/rfc/rfc6946.txt) from now on. 4) Now server B starts sending IPv6 atomic fragments... And since they include a frag header (and in '2)' above we noted that frags are dropped on that path), these packets get dropped (i.e., DoS). Demo with the icmp6 tool (http://www.si6networks.com/tools/ipv6toolkit) -- (some addresses have been changed (anonimized), but it is trivial to pick a victim server...) 2001:db8:1:10:0:1991:8:25 is the server, and 2001:5c0:1000:a::e7d is my own address): cut here * First of all, I telnet to port 80 of the server, and everything works as expected fgont@satellite:~$ telnet 2001:db8:1:10:0:1991:8:25 80 Trying 2001:db8:1:10:0:1991:8:25... Connected to 2001:db8:1:10:0:1991:8:25. Escape character is '^]'. ^CConnection closed by foreign host. Now I send the forget ICMPv6 PTB fgont@satellite:~$ sudo icmp6 --icmp6-packet-too-big -d 2001:db8:1:10:0:1991:8:25 --peer-addr 2001:5c0:1000:a::e7d --mtu 1000 -o 80 -v icmp6: Security assessment tool for attack vectors based on ICMPv6 error messages IPv6 Source Address: 2001:5c0:1000:a::e7d (automatically selected) IPv6 Destination Address: 2001:db8:1:10:0:1991:8:25 IPv6 Hop Limit: 227 (randomized) ICMPv6 Packet Too Big (Type 2), Code 0 Next-Hop MTU: 1000 Payload Type: IPv6/TCP (default) Source Address: 2001:db8:1:10:0:1991:8:25 (automatically-selected) Destination Address: 2001:5c0:1000:a::e7d Hop Limit: 237 (randomized) Source Port: 80 Destination Port: 38189 (randomized) SEQ Number: 734463213 (randomized) ACK Number: 866605720 (randomized) Flags: A (default) Window: 18944 (randomized) URG Pointer: 0 (default) Initial attack packet(s) sent successfully. * And now I try the same telnet command as above... but it fails, because the frags from the server to me are getting dropped somewhere fgont@satellite:~$ telnet 2001:db8:1:10:0:1991:8:25 80 Trying 2001:db8:1:10:0:1991:8:25... [timeout] cut here Of course, in this particular case I just shot myself. But one could do this to DoS connections between mailservers, etc. A nice question is: what if e.g 1) some BGP servers accept ICMPv6 PTB that claim an MTU 1280, and react (as expected) by generating atomic fragments, *and*, 2) These same BGP servers deem fragmentation as harmful, and hence drop such fragments you could essentially DoS traffic between them As noted in the I-D, the mitigations seem to be: 1) Artificially limit your packets to 1280, and drop all incoming ICMPv6 PTB, or, 2) Have your device just drop ICMPv6 PTB that claim a Next-Hop MTU smaller than 1280. Thoughts? -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Fwd: New IETF I-D: IPv6 Extension Headers in the Real World
Folks, FYI: http://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-in-real-world-00.txt. Comments welcome. Thanks! Fernando Forwarded Message Subject: New I-D: IPv6 Extension Headers in the Real World Date: Fri, 08 Aug 2014 00:04:37 -0400 From: Fernando Gont fg...@si6networks.com To: IPv6 Operations v6...@ietf.org Folks, We have published a new I-D on the topic of IPv6 Extension Headers (EHs). The I-D is available at: http://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-in-real-world-00.txt. Abstract: IPv6 Extension Headers allow for the extension of the IPv6 protocol, and provide support for some core functionality such as IPv6 fragmentation. However, IPv6 Extension Headers are deemed to present a challenge to IPv6 implementations and networks, and are known to be intentionally filtered in some existing IPv6 deployments. This summarizes the issues associated with IPv6 extension headers, and presents real-world data regarding the extent to which packets with IPv6 extension headers are filtered in the public Internet, and where in the network such filtering occurs. Additionally, it provides some guidance to operators in troubleshooting IPv6 blackholes resulting from the use of IPv6 extension headers. Finally, this document provides some advice to protocol designers, and discusses areas where further work might be needed. Comments and suggestions are welcome. Thanks! Best regards, Fernando Forwarded Message Subject: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-00.txt Date: Thu, 07 Aug 2014 20:57:17 -0700 From: internet-dra...@ietf.org To: J. Linkova fu...@google.com, Shucheng LIU (Will) liushuch...@huawei.com, Tim Chown t...@ecs.soton.ac.uk, Tim Chown t...@ecs.soton.ac.uk, Fernando Gont fg...@si6networks.com, Fernando Gont fg...@si6networks.com, Will (Shucheng) Liu liushuch...@huawei.com, J. Linkova fu...@google.com A new version of I-D, draft-gont-v6ops-ipv6-ehs-in-real-world-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-v6ops-ipv6-ehs-in-real-world Revision: 00 Title: IPv6 Extension Headers in the Real World Document date: 2014-08-07 Group: Individual Submission Pages: 15 URL: http://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-in-real-world-00.txt Status: https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-in-real-world/ Htmlized: http://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-world-00 Abstract: IPv6 Extension Headers allow for the extension of the IPv6 protocol, and provide support for some core functionality such as IPv6 fragmentation. However, IPv6 Extension Headers are deemed to present a challenge to IPv6 implementations and networks, and are known to be intentionally filtered in some existing IPv6 deployments. This summarizes the issues associated with IPv6 extension headers, and presents real-world data regarding the extent to which packets with IPv6 extension headers are filtered in the public Internet, and where in the network such filtering occurs. Additionally, it provides some guidance to operators in troubleshooting IPv6 blackholes resulting from the use of IPv6 extension headers. Finally, this document provides some advice to protocol designers, and discusses areas where further work might be needed. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: Requirements for IPv6 Firewalls
Hi, Brandon, On 04/17/2014 08:20 PM, Brandon Ross wrote: On Thu, 17 Apr 2014, Sander Steffann wrote: Also, I note your draft is entitled Requirements for IPv6 Enterprise Firewalls. Frankly, no enterprise firewall will be taken seriously without address-overloaded NAT. I realize that's a controversial statement in the IPv6 world but until you get past it you're basically wasting your time on a document which won't be useful to industry. I disagree. While there certainly will be organisations that want such a 'feature' it is certainly not a requirement for every (I hope most, but I might be optimistic) enterprises. And I not only agree with Sander, but would also argue for a definitive statement in a document like this SPECIFICALLY to help educate the enterprise networking community on how to implement a secure border for IPv6 without the need for NAT. Having a document to point at that has been blessed by the IETF/community is key to helping recover the end-to-end principle. Such a document may or may not be totally in scope for a firewall document, but should talk about concepts like default-deny inbound traffic, stateful inspection and the use of address space that is not announced to the Internet and/or is completely blocked at borders for all traffic. Are you argung against of e.g. default-deny inbound traffic? Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Requirements for IPv6 Firewalls
Folks, A few months ago we published an IETF I-D with requirements for IPv6 firewalls. Based on the feedback received since then, we've published a revision of the I-D: http://www.ietf.org/internet-drafts/draft-gont-opsec-ipv6-firewall-reqs-01.txt If you have any feedback/thoughts, please do let us know (please CC draft-gont-opsec-ipv6-firewall-r...@tools.ietf.org, such that all co-authors receive your feedback). FWIW, this I-D is being discussed on the IETF opsec wg list (op...@ietf.org, https://www.ietf.org/mailman/listinfo/opsec). Thanks! Best regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: Requirements for IPv6 Firewalls
Hi, David, Thanks so much for your feedback! -- Comments in-line On 04/17/2014 12:26 PM, David Newman wrote: The use of RFC 2544-esque metrics for firewall performance testing mostly benefits ill-informed or unscrupulous firewall marketeers, who send 1500-byte UDP packets and then brag about excellent performance. For firewalls handling TCP traffic, upper-layer traffic metrics such as HTTP object size, concurrent connection capacity, and connection setup rate are a lot more meaningful. The RFC 2544/2889 approach is OK if you only ever use your firewall as a router or a switch. The performance of a firewall used as an L2-L7 device should be measured with L2-L7 traffic. Are you referring to this text from our document? REQ GEN-5: The firewall MUST include performance benchmarking documentation. Such documentation MUST include information that reflects firewall performance with respect to IPv6 packet, but also regarding how IPv6 traffic may affect the performance of IPv4 traffic. The aforementioned documentation MUST be, at the very least, conditionally-compliant with both [RFC3511] and [RFC5180] (that is, it MUST support all MUST requirements in such documents, and may also support the SHOULD requirements in such documents). NOTE: This is for operators to spot be able to identify cases where a devices may under-perform in the presence of IPv6 traffic (see e.g. [FW-Benchmark]). XXX: This note may be removed before publication if deemed appropriate. Because he RFCs we reference do require to make the measurements as you describe... Thanks! Best regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: Requirements for IPv6 Firewalls
Hi, William! Thanks so much for your feedback! One meta comment: this document is an Internet-Draft, not an RFC. It's just the second version (-01) we have published... so it's not meant to be there. The reason for posting the I-D here was so that I could get your input as early in the production of this document as possible. Comments in-line On 04/17/2014 12:51 PM, William Herrin wrote: The feedback I would offer is this: You missed. By a lot. For one thing, many of the requirements are vague, like REQ APP-20. I've mitigated spam by allowing the operator to configure static packet filters for the bad guy's netblock, right? Requirements must be precise. Where you can't make it precise, drop it to a should. Ok, will expand REQ APP-20... And why is spam mitigation a firewall requirement in the first place? Traditionally that's handled by a specialty appliance, largely because it's such a moving target. Also, I note your draft is entitled Requirements for IPv6 Enterprise Firewalls. Frankly, no enterprise firewall will be taken seriously without address-overloaded NAT. Just double-checking: you're referring to NAT where the same address is mployed for multiple hosts in the local network, and where the transport-protocol port needs to be re-written by the NAT device? (i.e., a NAT-PT) I realize that's a controversial statement in the IPv6 world but until you get past it you're basically wasting your time on a document which won't be useful to industry. That's certainly controversial in the IPv6 world, but I have no problem with that. This sort of input (even much better if more people weigh) in is exactly what we're looking for. Such that when we apply the corresponding changes, and folks from other circles complain about them, I can point them to this sort of discussion. Thanks! Best regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: Requirements for IPv6 Firewalls
On 04/17/2014 06:48 PM, Matthew Kaufman wrote: On 4/17/2014 1:45 PM, George Herbert wrote: This is why listening to operators is important. Why start now? After all, most of the useful input operators could have provided would have been much more useful at the beginning. I cannot speak for that, unfortunately. But I can tell you that the reason for which we posted a note on this list regarding our I-D is because your feedback does matter to us (us == at least the co-authors of this document) Thanks! Best regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: real-world data about fragmentation
Hi, Joe, On 04/02/2014 03:14 PM, Joe Abley wrote: Is anybody aware of any wide-scale studies that examine the probability of fragmentation of datagrams of different sizes? We're in the process of measuring some (kind of related stuff). If you're interested in this data, we might be able to provide something along these lines in 1 month or so... It seems to be mostly about measuring the MTU to as many destinations as possible, so to speak... For example, I could reasonable expect an IPv4 packet of 576 bytes not to be fragmented very often (to choose a size not at random). Note: there shouldn't be any special magic around this number (usualy mistakenly interpreted as the minimum IPv6 MTU, but rather being the minimum IPv4 reassembly buffer size). The probability of a 10,000 octet IPv4 packet getting fragmented seems likely to be 100%, if we're talking about arbitrary paths across the Internet. What does the curve look like between 576 bytes and 10,000 bytes? I might expect exciting curve action around 1500 bytes (because ethernet), 1492 (PPPoE), 1480 (GRE), etc. But I'm interested in actual data. Anybody have any pointers? IPv4 and IPv6 are both interesting. Probably off-topic, but since you mentioned reliability of IPv6 fragmentation: * http://www.iepg.org/2013-11-ietf88/fgont-iepg-ietf88-ipv6-frag-and-eh.pdf * http://www.iepg.org/2014-03-02-ietf89/fgont-iepg-ietf89-eh-update.pdf Thanks! Cheers, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Question on DHCPv6 address assignment
Folks, I'm wondering about the following two aspects of different DHCPv6 implementations out there: 1) What's the pattern with which addresses are generated/assigned? Are they sequential (fc00::1, fc00::2, etc.)? Random? Something else? 2) What about their stability? Is there any intent/mechanism for them to be as stable as possible? Or is it usual for hosts to get a new address for each lease? P.S.: I understand this is likely to vary from one implementation to another... so please describe which implementation/version you're referring to. Thanks! Best regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: Question on DHCPv6 address assignment
Hi, Bill, On 01/31/2014 05:59 PM, bmann...@vacation.karoshi.com wrote: i in my bespoke version: Is there any reference I could use for it? 1- psudo-random within a /32 space 2- not stable, unless coded to a fixed address Regarding 2), do you mean they are only stable if you ahve a MAC-IPv6 mapping database, or something else? Cheers, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Fwd: Re: Some stats on IPv6 fragments and EH filtering on the Internet
Folks, FYI. Thought this might be of interest. P.S.: Input/comments welcome Thanks! Cheers, Fernando Original Message Subject: Some stats on IPv6 fragments and EH filtering on the Internet Date: Mon, 04 Nov 2013 15:01:48 -0800 From: Fernando Gont ferna...@gont.com.ar To: 6...@ietf.org 6...@ietf.org, IPv6 Operations v6...@ietf.org Folks, I did a presentation on the topic at the IEPG meeting earlier this week. It provides some concrete data regarding IPv6 fragmentation and Extension Header filtering on the Internet. The slideware is available at: http://www.iepg.org/2013-11-ietf88/fgont-iepg-ietf88-ipv6-frag-and-eh.pdf Certainly there's *much* more work to be done in this area, but I thought that this could be good food sfor some of the discussions that we were having on the topic. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 Original Message Subject: Re: Some stats on IPv6 fragments and EH filtering on the Internet Date: Mon, 4 Nov 2013 23:27:12 + From: Tim Chown t...@ecs.soton.ac.uk To: 6...@ietf.org 6...@ietf.org, IPv6 Operations v6...@ietf.org Hi, Also as per the IEPG discussion, the results I had in conjunction with a summer MSc project student can be summarised as follows. The headline is that he saw a 37.7% failure rate for the Fragmentation Header (alone), a bit better than Fernandos results, but still not good. He tested the top 1,000 IPv6-enabled Alexa sites. He used the scapy toolkit which supports the four main extension header types (routing, fragmentation, destination and hop-by-hop) He tested a) valid combinations of those 4 extension headers as per RFC 2460 b) other non-valid combinations c) duplicated extension headers d) fragmentation header Primarily TCP tests, doing HTTP GET requests. For single extension headers, acceptance was Routing header 63.9% Frag header 62.3% Hop by hop header 60% Destination option header 15.8% When using no extension headers, success rate was 100% When using multiple headers, the rates fall markedly, not dissimilar with Fernandos numbers for longer headers. About 120 sites accept all four types of extension headers. A small number of sites accepted illegal combinations/ordering of extension headers. A more detailed set of results is being pushed to a conference paper. I now have another student taking this further, and validating the above results, so feel free to contact me off-list if youre interested. Tim On 4 Nov 2013, at 23:01, Fernando Gont ferna...@gont.com.ar wrote: Folks, I did a presentation on the topic at the IEPG meeting earlier this week. It provides some concrete data regarding IPv6 fragmentation and Extension Header filtering on the Internet. The slideware is available at: http://www.iepg.org/2013-11-ietf88/fgont-iepg-ietf88-ipv6-frag-and-eh.pdf Certainly there's *much* more work to be done in this area, but I thought that this could be good food sfor some of the discussions that we were having on the topic. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 IETF IPv6 working group mailing list i...@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list i...@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Article: IPv6 addressing requires special attention to ensure security
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Folks, I've just realized that about a month ago Techtarget published an article I authored for them entitled IPv6 addressing requires special attention to ensure security. The article is available at: http://searchnetworking.techtarget.com/tip/IPv6-addressing-requires-special-attention-to-ensure-security (the ful article is available at the aforementioned URL, *without* the need to register --- just scroll down past the ad as necessary). Thanks, - -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJR6/5AAAoJEJbuqe/Qdv/x9f4IAK+ST64iqq/LXVAcEojhv94f 2wovt/fK/tjBXrm8xy0XjiQCnit/tAULnRFtBxmpw4dwgWO9Ih6npELHCTC+loia olbONSb9y60iP4I8Deou5+V8jVv6sdDwxSFJP32ZVFN2GoPGyzIPN02qDIrbAtUT TwVmWsgcJopb9IWnd/NTgTsRzu7a2eeiS/9Nfm0Qdth7LRQhD+pU90lbI0lCxPCT 2cT42rFfP6hC2cieMWwVvghT3tbaL04qU7YPV3LIshbaPaYk6R8KZPYg4kzNs6z4 h1g3EEl6RShCxYAYZAKvF7I4bkZof71nQ21JdelaVHPBUKhpSffrKzfjufHh89M= =a7O6 -END PGP SIGNATURE-
ipv6hackers Meeting in Berlin (July 30, 2013)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 FYI Folks, We finally put everything in place to announce the very first IPv6 Hackers meeting. All the relevant info is available at:: http://www.ipv6hackers.org/meetings/berlin-2013 - cut here IPv6 Hackers Meeting - Berlin 2013 ** What ** - From a couple of years now, we have had a mailing-list devoted to IPv6 hacking (i.e., testing, tools, low-level stuff, etc.), home of the ipv6hackers group. The mailing-list (charter, subscription options, etc.) is available at: http://lists.si6networks.com/listinfo/ipv6hackers/. We're planning to have our first in-person meeting, which will feature a number of presentations (which MUST be accompanied with code and/or measurements/testing). ** When ** July 30 (Tuesday), 2013. From 16:00 to 19:00. ** Where ** Salzufer 14, 10587 Berlin, Germany. EANTC AG (European Advanced Networking Test Center) Headquarters. If you'll be arriving from the IETF 87 venue (Intercontinental Berlin), it's about a 30-minute walk. Maps available here: http://www.ipv6hackers.org/meetings/berlin-2013 ** How to participate ** The meeting is open for participation, at no cost. If you have any interesting stuff to present, please send the following information to i...@ipv6hackers.org *before* July 23, 2013: * Proposed presentation title * Abstract * Speaker name Note: All presentations must be practical in nature. They must feature tools, testing, and/or measurements. - cut here - -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 - -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJR4Z09AAoJEJbuqe/Qdv/xWhAH/ik4G3eHmLLOXj30xcq3AXwW 62YMvUWcpsPGGrZxvi05Id5ZJGYanitt5bCXIiqVKsgtn56wCXspxpvmTOyWBwqX nlTkravMaCgrYFXvQUTri8UXoRSITdIlrnKdjf5JqG8jiCEBwgpuAqFzryXCElk2 YX5Ygq0fXpcvRI6WNY965eGK9sU2cTtYb9BUTiE9O/eNIv8/EX/2EyQIVVUxWVFt QXcWTYnJXdb9Lleeb3hT/95XjS7zShUpHGzHXt+tRorpDHd3v0+Ygkqreu9BQpTp i1ukUTbSkrj7TGDSVqyKDU+BPoGKIQPHz+CCMpW3M0Z7uIawSjIv3PdepV6Ryy0= =08PE -END PGP SIGNATURE-
SI6 Networks' IPv6 Toolkit v1.3.4 released!
Folks, We have just released SI6 Networks' IPv6 Toolkit v1.3.4: a security assessment and troubleshooting toolkit for the IPv6 protocol suite. The toolkit is available at: http://www.si6networks.com/tools/ipv6toolkit, where you can find a the usual tarball, a GPG-signed version of it, a link to the toolkit's GIT repository, etc. This release features: * IPv6-host tracking support in the scan6 tool. * A new tool, address6, to analyze IPv6 addresses * Minor bug fixes The toolkit runs on (at least) the latest versions of Linux, FreeBSD, NetBSD, OpenBSD, and MacOS. Please send any bug reports and/or feature requests to fg...@si6networks.com. As always, you can get the latest news on IPv6 security research and tools by following us on Twitter: @SI6Networks. And if you're into IPv6 hacking, please consider joining the ipv6hackers mailing list: http://www.si6networks.com/community/mailing-lists.html. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
SI6 Networks IPv6 Toolkit v1.3 released!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Folks, We are pleased to release the SI6 Networks' IPv6 Toolkit v1.3: a security assessment and trouble-shooting toolkit for the IPv6 protocol suite. The toolkit is available at: http://www.si6networks.com/tools/ipv6toolkit, where you can find a the usual tarball, a PGP-signed version of it, a link to the toolkit's GIT repository, etc. This release has a number of features: * It includes a full-fledged IPv6 address scanning tool (scan6) -- probably the only comprehensive IPv6 address scanning tool out there. Check out all the newly incorporated features! * It includes support for tunnels (in most of the tools). So if you are currently employing e.g. a free IPv6 tunnel to connect to the IPv6 Internet, you'll now be able t play with the tools using your tunnel. * Adds features that have been in our todo list for a while: + It includes manual pages in troff format for all the tools. + It includes a makefile, to easily build and install the tools, configuration file, manuals, etc., on your local system. The toolkit runs on (at least) the latest versions of Linux, FreeBSD, NetBSD, OpenBSD, and Mac OS X. Please send any bug reports and/or feature requests to fg...@si6networks.com. As always, you can get the latest news on IPv6 security research and tools by following us on Twitter: @SI6Networks. Thanks! Best regards, - -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 - -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRH81hAAoJEJbuqe/Qdv/xvogH/jpydcxEaII0cRMoF7r9yDfL uV4LJYYsGg56pHn07UEaa8SWFtZP5/ynuq+9A9bmPuXzuRshOLj87MBqL3FOBAXO 9C6GwiyHP/OfpkLC+QIEp2WlNMFQ4n2d0/wIotKvMtz7XZMKkYyP2Awcu0yQTH/f /EglnuOvXWFNgz+CI1FcRFJ5+TOWJjFf5AnNT44toVcVzDEiaXDcp2xcAyLX+bmn 3WrNUIjZtV4hibwbrxxPrHHC+0U6YxfW2aqNfI3PMWl2N9GdoJAOHsQT6Qn6TyXG +AjPoCaZI/RovWpDEYM2Z8UcvHwFOgBguwIgqKO0/3rw78co8OziJNtWd2lCJkI= =Rrjk -END PGP SIGNATURE-
How to avoid security issues with VPN leaks on dual-stack networks
Folks, Thought you might be interested... Techtarget has just published an article I've authored for them, entitled How to avoid security issues with VPN leaks on dual-stack networks. The article is available at: http://searchsecurity.techtarget.com/tip/How-to-avoid-security-issues-with-VPN-leaks-on-dual-stack-networks (Note: There are some banners (?) intermixed... but the whole article can be viewed without registration... just keep scrolling down!) Its Abstract is: cut here The imminent exhaustion of freely available IPv4 addresses has, over a number of years, led to the incorporation of IPv6 support by most general-purpose operating systems. However, many applications, such as VPN client and server software, have been lagging behind to become IPv6-ready. This results in scenarios in which dual-stacked hosts employ IPv6-unaware VPN software, thus opening the door to security vulnerabilities, such as VPN traffic leaks. In this tip, we'll discuss how these VPN security issues arise and the various mitigation options available for containing VPN traffic leaks. cut here P.S.: Any comments will be welcome. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: Dropping IPv6 Fragments
Hi, Joel, On 10/04/2012 10:58 AM, joel jaeggli wrote: So the thing I'd note is that stateless IPV6 ACLs or load balancing provide you with an interesting problem since a fragment does not contain the headers beyond the required unfragmentable headers. In the real world, such packets are not legitimate, so feel free to drop them. draft-ietf-6man-oversized-header-chain formally addresses this issue. Likewise with the acl I have the property that the initial packet has all the info in it while the fragment does not. You're talking about initial-fragment vs non-initial fragments? -- If so, in theory *both* might be missing the upper layer information. IN practice, the first-fragment won't. If it does, feel free to drop it. Cheers, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
ipv6mon v1.0 released! (IPv6 address monitoring daemon)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Folks, We are pleased to announce the release of ipv6mon v1.0! ** Description ** ipv6mon (http://www.si6networks.com/tools/ipv6mon) is a tool for monitoring IPv6 address usage on a local network. It is meant to be particularly useful in networks that employ IPv6 Stateless Address Auto-Configuration (as opposed to DHCPv6), where address assignment is decentralized and there is no central server that records which IPv6 addresses have been assigned to which nodes during which period of time. ipv6mon employs active probing to discover IPv6 addresses in use, and determine whether such addresses remain active. ** Latest release ** The latest release of ipv6mon is v1.0, and is available at: http://www.si6networks.com/tools/ipv6mon/ipv6mon-v1.0.tar.gz ** Documentation ** PDF versions of the ipv6mon manuals are available on-line at: http:://www.si6networks.com/tools/ipv6mon ** GIT repository ** The GIT repository for the ipv6mon is: https://github.com/fgont/ipv6-toolkit.git ** IPv6 security trainings ** Development of ipv6mon is partially supported through our IPv6 security trainings. Please consider attending one of our upcoming trainings http://www.hackingipv6networks.com/upcoming-t Follow us on twitter: @SI6Networks Best regards, - -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 - -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJQUc+lAAoJEJbuqe/Qdv/xHc0IAJ8rTfjwisnAKxDrlXiQpNjZ 3yJbWE3LPEj5wTkoqHgOkd0p6h+hEkz9yaxlSyoZTJAP/N2IOvmdWdmXpV5umTen cVRxn5HopYRL4kEDRu5rc7DiwWXPXiuAZD8uvyyc/u/TiLHJXePjK1Cicp1W/iIZ cSBAKcjMGpaYX0i/Vj2rN36gytrjW0jRlF8e3+64FHss1+poEG58TBLcZyckZkTZ TqE1G184gkAPAa8DryT8U1k68ZWWO/2gWMsLR/nTxjUmSZHamPrZHN2IHlhdC5vu ABBK/M13MIepNfnFlXfBMCTMy0CQU87kRwo5OF+1M7NAeshovmgjtOp+idAsZec= =a76/ -END PGP SIGNATURE-
Re: ipv6mon v1.0 released! (IPv6 address monitoring daemon)
On 09/13/2012 09:31 AM, Jeroen Massar wrote: ipv6mon employs active probing to discover IPv6 addresses in use, and determine whether such addresses remain active. You mean, like what NDPMon has been delivering for several years already: Does NDPMon do active probing? If it doesn't, it's not like what NDPMon has been delivering for several years already. For instance, ipv6mon is not meant to be analogous to arpwatch, and is *not* meant to detect ND attacks. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
IPv6 Toolkit v1.2.2 released
Folks, We've released IPv6 toolkit version 1.2.2. It is available at: http://www.si6networks.com/tools (tarball and git repository). This version is meant to be fully-portable to Mac OS (the list of supported systems now including, at the very least, FreeBSD, NetBSD, OpenBSD, Linux, and Mac OS), and also incorporates a number of patches send by the community. Any feedback on the tools will be welcome (either unicast to me, or on the ipv6hackers mailing-list http://lists.si6networks.com/listinfo/ipv6hackers/). P.S.: If you've sent patches and your patches have not yet been applied, most likely it just means that I'm catching-up with them (feel free to resend!). Thanks! Best regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
IPv6 Toolkit v1.2: Latest snapshot, and git repo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Folks, I've posted a snapshot (tarball) of my working copy of the IPv6 toolkit. The tarball is available at: http://www.si6networks.com/research/ipv6-toolkit-v1.2.tar.gz Additionally, I've created a git repository for the toolkit, such that collaboration is improved. The git repo is available at: https://github.com/fgont/ipv6-toolkit.git If you have access to a Mac OS box, please try to compile the tools, and let me know if you find any errors (or let me know if they compiled cleanly). If you can also run the tools according to some of the examples in the manuals (and report any problems), that would be great, too. P.S.: If you've sent patches and your patches have not yet been applied, most likely it just means that I'm catching-up with them (feel free to resend!). Thanks! Best regards,-- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJQAtn3AAoJEJbuqe/Qdv/xYIgH+wTQXJ3iNEnGnA0cMazS32py 3HfTdcMaEphnfF2a15dq1h/uqF05g3t9KqU744A1XmMtDlChvQ2I77uj2amqaeKi dED6e/NTuVAxTAI0ZTPIEn7BkDgtqvhuaoth+E4SX73lJC9eJR7e3T3BAtbESZaQ Sp67lvtgYmqogDc0IQALGNucyhHmacfUBocVLVgmVPn8BwdFxHI80W+Vc6TnKfjm Yc9ijgUPLTu0hOGD4bpOeQ2V3Dzw9PW17PyJlPr3TzWLzb8g64/zZROtHjXl/V4s 0JNAZVrHNDvA7kfEujzsoLcnQLCfq3+jzecvXcGwgsYMDXRBL8Lv628OAhrVglY= =Z3+1 -END PGP SIGNATURE-
IPv6 security tools released
Folks, A bunch of IPv6 security tools I produced these last couple of years have been posted online at: http://ipv6securitylab.org/ipv6toolbox.html. Not sure whether this was really intended, but since a number of folks have already noted (off-list) that this release has been announced on a number of pages and twitter accounts, I thought it would be better to let you guys know about it (i.e., the cat is out of the bag, already). The tools compile run on Linux and *BSD, and I'm planning to port them to Mac OS too (if only I had such a box... sigh :-) ). Any feedback will be welcome. P.S.: The slideware at: http://www.si6networks.com/presentations/hip2012/fgont-hip2012-hacking-ipv6-networks-training.pdf might give you some hints regarding how to use some of the tools. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
New I-D on SLAAC DNS configuration problems (Fwd: New Version Notification for draft-gont-6man-slaac-dns-config-issues-00.txt)
Folks, We have published a new Internet-Draft entitled Current issues with DNS Configuration Options for SLAAC. This draft if meant to address the SLAAC DNS configuration issues raised by Pavel on the 6man mailing-list, and also discusses other potential issues. The I-D is available at: http://www.ietf.org/internet-drafts/draft-gont-6man-slaac-dns-config-issues-00.txt The I-D is aimed at 6man, so please considering weighing in the corresponding mailing-list (that of the 6man wg). Any comments will be highly appreciated (including off-list and posts to the nanog list). Thanks! Best regards, Fernando Original Message Subject: New Version Notification for draft-gont-6man-slaac-dns-config-issues-00.txt Date: Thu, 14 Jun 2012 18:36:26 -0700 From: internet-dra...@ietf.org To: fg...@si6networks.com CC: pav...@pavlix.net A new version of I-D, draft-gont-6man-slaac-dns-config-issues-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Filename:draft-gont-6man-slaac-dns-config-issues Revision:00 Title: Current issues with DNS Configuration Options for SLAAC Creation date: 2012-06-15 WG ID: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-gont-6man-slaac-dns-config-issues-00.txt Status: http://datatracker.ietf.org/doc/draft-gont-6man-slaac-dns-config-issues Htmlized: http://tools.ietf.org/html/draft-gont-6man-slaac-dns-config-issues-00 Abstract: RFC 6106 specifies two Neighbor Discovery options that can be included in Router Advertisement messages to convey information about DNS recursive servers and DNS Search Lists. Small lifetime values for the aforementioned options have been found to cause interoperability problems in those network scenarios in which these options are used to convey DNS-related information. This document analyzes the aforementioned problem, and formally updates RFC 6106 such that these issues are mitigated. The IETF Secretariat -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
IETF I-D: Current issues with DNS Configuration Options for SLAAC
Folks, We have published a new IETF I-D entitled Current issues with DNS Configuration Options for SLAAC, about existing problems with the DNS configuration options used with SLAAC. The I-D is available at: http://tools.ietf.org/id/draft-gont-6man-slaac-dns-config-issues-00.txt. Abstract: cut here RFC 6106 specifies two Neighbor Discovery options that can be included in Router Advertisement messages to convey information about DNS recursive servers and DNS Search Lists. Small lifetime values for the aforementioned options have been found to cause interoperability problems in those network scenarios in which these options are used to convey DNS-related information. This document analyzes the aforementioned problem, and formally updates RFC 6106 such that these issues are mitigated. cut here This version of the I-D discusses different *alternative* mitigations for the forementioned problem. Your input will be very appreciated. Thanks! Best regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: Article: IPv6 host scanning attacks
do it. PPS: There seems to be a diagram missing in the discussion of embedded MAC addresses, after the word syntax. Will check. Thanks! Cheers, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: Article: IPv6 host scanning attacks
On 06/13/2012 05:22 PM, STARNES, CURTIS wrote: Going from an IPv4 32 bit address space to a IPv6 128 bit address space like you mentioned in the article would be a tedious effort to scan. (tedious != infeasible) (tedious 5 years) -- that's the point the article is trying to make. That sounds fine and dandy but in reality, Internet facing IPv6 native or dual-stack systems that are installed with any security forethought at all would not embed any of these options with the exception of the last one (transitional or coexistence) only if forced to do so. Well, as far as I've measured, they do. I agree that some IPv6 addresses are set up to have catchy names, but why set up hundreds or even thousands of IPv6 addresses with IPv6 addresses that you try to remember like we did with IPv4? Because that's what you're used to? -- and no, I'm not arguing in favor of that, but rather accepting human's resistance to change. In general, I just don't agree with your conclusions, and with proper IPv6 firewall rules, the network should still be as secure as the IPv4 systems. Not more insecure just because they run an IPv6 stack. Your making a much broader claim here. When it comes to scanning attacks, they are likely to be harder than for the IPv4 case. However, when it comes to IPv6 security vs. IPv4 security, I'd expect v6 to be worse than v4, not (necessarily/only) for the protocol itself -- please see slide 8 of http://www.si6networks.com/presentations/deepsec2011/fgont-deepsec2011-ipv6-security.pdf Cheers, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Article: IPv6 host scanning attacks
Folks, TechTarget has published an article I've authored for them, entitled Analysis: Vast IPv6 address space actually enables IPv6 attacks. The aforementioned article is available at: http://searchsecurity.techtarget.com/tip/Analysis-Vast-IPv6-address-space-actually-enables-IPv6-attacks (FWIW, it's a human-readable version of the IETF Internet-Draft I published a month ago or so about IPv6 host scanning (see: http://tools.ietf.org/html/draft-gont-opsec-ipv6-host-scanning)) You can get news about this sort of stuff by following @SI6Networks on Twitter. Cheers, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Heads up: IETF 6man poll for adoption of RA-Guard/firewalling/monitoring-related I-Ds
Folks, Just wanted to send a heads up regarding two IETF 6man wg polls that have just been started for adoption of these documents: * draft-gont-6man-oversized-header-chain-02 (Security and Interoperability Implications of Oversized IPv6 Header Chains) * draft-gont-6man-nd-extension-headers-03 (Security Implications of the Use of IPv6 Extension Headers with IPv6 Neighbor Discovery) draft-gont-6man-oversized-header-chain-02 requires that when packets are fragmented, the first fragment must contain the entire IPv6 header chain. This is important for a number of reasons: it allows for stateless filtering (both at firewalls and at RA-Guard-like devices), prevents stateless translators from breaking, etc. The poll for this document is available at: http://www.ietf.org/mail-archive/web/ipv6/current/msg15989.html draft-gont-6man-nd-extension-headers-03 forbids the use of fragmentation with Neighbor Discovery. This essentially enables Neighbor Discovery monitoring in IPv6, thus providing feature parity with IPv4 (think about arpwatch and the like) -- not to mention that it obviously mitigates fragmentation-based attacks against Neighbor Discovery and SEND. The poll for this document is available at: http://www.ietf.org/mail-archive/web/ipv6/current/msg15990.html IMO, these two I-Ds propose small spec updates which could result in concrete operational and security benefits. Thanks! Best regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: Article: IPv6 host scanning attacks
On 06/13/2012 02:28 PM, Dave Hart wrote: The aforementioned article is available at: http://searchsecurity.techtarget.com/tip/Analysis-Vast-IPv6-address-space-actually-enables-IPv6-attacks published and available are misleading at best. It is not. Just scroll down the page, and you'll find the whole article. -- it was easy to talk crap than to do that, right? The article is teased with a sentence and a half, truncated by a demand for an email address with tiny legalese mentioning a privacy policy and terms of use that undoubtedly would take far longer to read than Gont's valuable content. You don't need to read that to scroll the page down past it. (FWIW, it's a human-readable version of the IETF Internet-Draft I published a month ago or so about IPv6 host scanning (see: http://tools.ietf.org/html/draft-gont-opsec-ipv6-host-scanning)) I guess I'll take a look at this to see what you're smoking. I find it amazing the number of people that will talk crap when one publishes something when compared to the number of people that provides technical comments or criticism (even if it's you're completely wrong because of this and that). Read the article. Have something to add or complain about the technical contents? -- Do it. But otherwise try to keep a good signal/noise ratio, please. You can get news about this sort of stuff by following @SI6Networks on Twitter. news in quotes is appropriate given it's really eyeball harvesting for marketing purposes. Please do the math regarding the number of posts/tweets announcing publications to the number of posts/tweets doing marketing (probably just those about trainings). Then comment. Cheers, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: Article: IPv6 host scanning attacks
On 06/13/2012 03:37 PM, Dave Hart wrote: published and available are misleading at best. It is not. Just scroll down the page, and you'll find the whole article. -- it was easy to talk crap than to do that, right? Yes, I'm an idiot for believing what I read on that site: Requires Free Membership to View Of course I should have expected that means scroll past me and the page of whitespace to view. I wouldn't announce the publication of an article that implies the hassle of a registration in order to read it. While it's certainly not as good as it can get to have a banner saying require free membership to view inserted in the middle of the article body, it's still acceptable for me. (Since you're not the first one to think that the article was not free, next time I'll probably make this explicit such that possible trouble is avoided]). I find it amazing the number of people that will talk crap when one publishes something when compared to the number of people that provides technical comments or criticism (even if it's you're completely wrong because of this and that). The draft and the article raise valid points about the predictability of widely-used MAC-derived IIDs, but it does not in any way justify the headline Analysis: Vast IPv6 address space actually enables IPv6 attacks. Whomever wrote that should share their stash. FWIW, the headline was replaced prior to publication. Put another way: I agree with your comment regarding the headline. Cheers, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
IPv6 security: New IETF I-Ds, slideware and videos of recent presentations, trainings, etc...
Folks, * We've published a new IETF I-D entitled DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers, which is meant to provide RA-Guard-like protection against rogue DHCPv6 servers. The I-D is available at: http://tools.ietf.org/id/draft-gont-opsec-dhcpv6-shield-00.txt Other IPv6 security I-Ds (such as, draft-ietf-v6ops-ra-guard-implementation) have been revised. Please check them out at: http://www.si6networks.com/publications/ietf.html * The slideware (and some videos!) of some of our recent presentations about IPv6 security are now available online. You can find them at: http://www.si6networks.com/presentations/index.html * We have also scheduled IPv6 hacking trainings in Paris (France) and Ghent (Belgium). You can find more details at: http://www.si6networks.com/index.html#conferences Our Twitter: @SI6Networks ipv6hackers mailing-list: http://lists.si6networks.com/listinfo/ipv6hackers/ Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: Vendor IPv6 RA Guard Support
On 04/28/2012 09:11 AM, Christopher J. Pilkington wrote: Does there exist a multi-vendor list showing whether a particular switch hardware/software supports or does not support RA Guard? Last time (a couple of months ago, or so) this was discussed on the ipv6hackers mailing-list (http://lists.si6networks.com/listinfo/ipv6hackers/), comments were that no vendor had addressed this, yet. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: New IETF I-D: Security Implications of IPv6 on IPv4 networks
FYI, I posted a rev of this I-D a couple of days ago, and hence the previous document was automatically removed (thus resulting in a broken link). The latest version of this document is always available at the magic URL: http://tools.ietf.org/html/draft-gont-opsec-ipv6-implications-on-ipv4-nets Apologies for the possible inconvenience. Thanks, Fernando On 04/24/2012 07:20 AM, Fernando Gont wrote: Folks, We've published a new IETF I-D entitled Security Implications of IPv6 on IPv4 networks. The I-D is available at: http://www.ietf.org/id/draft-gont-opsec-ipv6-implications-on-ipv4-nets-00.txt The Abstract of the I-D is: cut here This document discusses the security implications of native IPv6 support and IPv6 transition/co-existence technologies on IPv4-only networks, and describes possible mitigations for the aforementioned issues. cut here Any feedback will be very welcome. Thanks! Best regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
New IETF I-D: Security Implications of IPv6 on IPv4 networks
Folks, We've published a new IETF I-D entitled Security Implications of IPv6 on IPv4 networks. The I-D is available at: http://www.ietf.org/id/draft-gont-opsec-ipv6-implications-on-ipv4-nets-00.txt The Abstract of the I-D is: cut here This document discusses the security implications of native IPv6 support and IPv6 transition/co-existence technologies on IPv4-only networks, and describes possible mitigations for the aforementioned issues. cut here Any feedback will be very welcome. Thanks! Best regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Fwd: Host scanning in IPv6 Networks
FYI Original Message Subject: IPv6 host scanning in IPv6 Date: Fri, 20 Apr 2012 03:57:48 -0300 From: Fernando Gont fg...@si6networks.com Organization: SI6 Networks To: IPv6 Hackers Mailing List ipv6hack...@lists.si6networks.com Folks, We've just published an IETF internet-draft about IPv6 host scanning attacks. The aforementioned document is available at: http://www.ietf.org/id/draft-gont-opsec-ipv6-host-scanning-00.txt The Abstract of the document is: cut here IPv6 offers a much larger address space than that of its IPv4 counterpart. The standard /64 IPv6 subnets can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than their IPv4 counterparts. As a result, it is widely assumed that it would take a tremendous effort to perform host scanning attacks against IPv6 networks, and therefore IPv6 host scanning attacks have long been considered unfeasible. This document analyzes the IPv6 address configuration policies implemented in most popular IPv6 stacks, and identifies a number of patterns in the resulting addresses lead to a tremendous reduction in the host address search space, thus dismantling the myth that IPv6 host scanning attacks are unfeasible. cut here Any comments will be very welcome (note: this is a drafty initial version, with lots of stuff still to be added... but hopefully a good starting point, and a nice reading ;-) ). Thanks! Best regards,
Re: Host scanning in IPv6 Networks
Hi, Jimmy, On 04/20/2012 09:22 PM, Jimmy Hess wrote: The mathematical argument in the draft doesn't really work, because it's too focused on there being one specific site that can be scanned. Not sure what you mean. Clearly, in the IPv6 world you'd target specific networks. How could you know which networks to scan? -- Easy: the attacker is targeting a specific organization, are you gather possible target networks as this information leaks out all too often (e-mail headers, etc.). You can't just pick a random 120 bit number and have a good chance of that random IP happening to be a live host address. That would be pretty much a brute force attack, and the argument in this paper is that IPv6 host-scanning attacks will not be brute force (as we know them). The draft is unconvincing. The expected result is there will be very little preference for scanning, and those that will be launching attacks against networks will be utilizing simpler techniques that are still highly effective and do not require scanning. Not sure what you mean. Could you please clarify? Such as the exploit of vulnerable HTTP clients who _navigate to the attacker controlled web page_, walking directly into their hands, instead of worms searching for needles in haystacks. Well, this is part of alternative scanning techniques, which so far are not the subject of this draft. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
IPv6 NIDS evasion and IPv6 fragmentation/reassembly improvements
Folks, FYI, http://blog.si6networks.com/2012/02/ipv6-nids-evasion-and-improvements-in.html It contains some test results regarding the implementation of RFC 5722 and draft-ietf-6man-ipv6-atomic-fragments. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Fwd: IPv6 RA-Guard: Advice on the implementation (feedback requested)
Folks, Not sure if I had posted on this list about RA-Guard evasion issues. Anyway...nowadays most implementations remain vulnerable. If you care to get this fixed, please provide feedback about this I-D on the IETF *v6ops* mailing-list v6...@ietf.org, and CC me if possible (please see below). Thanks! Best regards, Fernando Original Message Subject: RA-Guard: Advice on the implementation (feedback requested) Date: Wed, 01 Feb 2012 21:44:29 -0300 From: Fernando Gont fg...@si6networks.com Organization: SI6 Networks To: IPv6 Operations v6...@ietf.org Folks, We have just published a revision of our I-D Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-implementation-01.txt. In essence, this is the problem statement, and what this I-D is about: * RA-Guard is essential to have feature parity with IPv4. * Most (all?) existing RA-Guard implementations can be trivially evaded: if the attacker includes extension headers in his packets, the RA-Guard devices fail to identify the Router Advertisement messages. -- For instance, THC's IPv6 attack suite (http://www.thc.org/thc-ipv6/) contains tools that can evade RA-Guard as indicated. * The I-D discusses this problem, and provides advice on how to implement RA-Guard, such that the aforementioned vulnerabilities are eliminated, we have an effective RA-Guard device, and hence feature-parity with IPv4. We'd like feedback on this I-D, including high-level comments on whether you support the proposal in this I-D. Thanks! Best regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
IPv6 Hackers mailing-list
Folks, We have created the IPv6 Hackers mailing-list for discussion of IPv6 security issues and low-level issues. The charter of the list is: cut here This list was created for the discussion of IPv6 security issues and low/packet-level issues related to the IPv6 protocols. It is meant to provide forum for IPv6 security researchers and IPv6 networking professionals to discuss low-level IPv6 networking and security issues that could eventually lead to advances and improvements in the area of IPv6 security and IPv6 networking. Discussion of unrelated networking or security topics are considered off topic. Subscription to the list is open to the community. cut here You can subscribe to the mailing-list here: http://lists.si6networks.com/listinfo/ipv6hackers/ Thanks! Best regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
