tag:blogger.com,1999:blog-42128238840818823742024-03-06T01:33:34.425-03:00Fernando Gont's BlogInternet Engineering, Information Security, Computer Networking....Unknownnoreply@blogger.comBlogger27125tag:blogger.com,1999:blog-4212823884081882374.post-18716554937818245842011-08-10T12:25:00.001-03:002011-08-10T12:26:56.016-03:00Password Strength<div class="separator" style="clear: both; text-align: center;"><a href="http://imgs.xkcd.com/comics/password_strength.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="322" src="http://imgs.xkcd.com/comics/password_strength.png" width="400" /></a></div><br />
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4212823884081882374.post-71989178456699862412011-07-27T22:21:00.000-03:002011-07-27T22:21:27.226-03:00Hacking IPv6 Networks<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhbR-D2amqtxIT518531xE6-H_11kuaKMivtfrtYUdLBCSohZ4Ihsx7NHbS3lFc4Wg8wrpN8A7T5HPcoCyM3evF2FfiiTXY9SS4cwH5Uoyvk8nfLXwkJbqp8pLg55J9-Luw9uvDAlcXW6o/s1600/hipv6networks-profile-jpg.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhbR-D2amqtxIT518531xE6-H_11kuaKMivtfrtYUdLBCSohZ4Ihsx7NHbS3lFc4Wg8wrpN8A7T5HPcoCyM3evF2FfiiTXY9SS4cwH5Uoyvk8nfLXwkJbqp8pLg55J9-Luw9uvDAlcXW6o/s200/hipv6networks-profile-jpg.jpg" width="200" /></a></div>We have launched a series of in-depth, hands-one trainings about IPv6 security.<br />
<br />
The first edition was last June, at the Hack in Paris 2011 conference in Paris, France.<br />
<br />
The next edition will be in Sao Paulo, Brazil.<br />
<br />
Check out the training's <a href="http://www.hackingipv6networks.com/">web site</a>!Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4212823884081882374.post-85161252288958933672011-07-05T18:20:00.001-03:002011-07-11T06:02:24.833-03:00IETF RFC 6274: Security Assessment of the Internet Protocol Version 4The IETF has published <a href="http://www.rfc-editor.org/rfc/rfc6274.txt">RFC 6274</a>, entitled "Security Assessment of the Internet Protocol Version 4", which is an IETF version of the <a href="http://www.gont.com.ar/papers/InternetProtocol.pdf">IPv4 security assessment</a> that had been published by <a href="http://www.cpni.gov.uk/">CPNI</a> in 2008. The Abstract of the RFC is:<br />
<br />
<blockquote><i>This document contains a security assessment of the IETF<br />
specifications of the Internet Protocol version 4 and of a number of<br />
mechanisms and policies in use by popular IPv4 implementations. It<br />
is based on the results of a project carried out by the UK's Centre<br />
for the Protection of National Infrastructure (CPNI).</i></blockquote><br />
The RFC is available <a href="http://www.rfc-editor.org/rfc/rfc6274.txt">here</a>.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4212823884081882374.post-56752436949228467252011-07-05T17:20:00.004-03:002011-07-27T22:11:53.582-03:00Requirements for secure IPv6 deployments include better IPv6 tester tools<div style="font-family: inherit;">An article that I've authored for techtarget.com has just been published. It is entitled "<a href="http://searchsecurity.techtarget.com/tip/Requirements-for-secure-IPv6-deployments-include-better-IPv6-tester-tools">Requirements for secure IPv6 deployments include better IPv6 tester tools</a>". The "abstract" of the article is:<br />
<blockquote style="font-family: Verdana,sans-serif;"><i>This article, which is a part of the SearchSecurity.com mini learning guide, IPv6 tutorial: Understanding IPv6 security issues, threats, defenses, discusses how a number of factors, such as a lack of trained personnel and limited IPv6 support in security devices, may affect the security of IPv6 network deployments. It also explains the potential effects of those factors, and suggests possible ways to mitigate these shortcomings.</i></blockquote></div><div style="font-family: inherit;">The full article is available <a href="http://searchsecurity.techtarget.com/tip/Requirements-for-secure-IPv6-deployments-include-better-IPv6-tester-tools">here</a>.</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4212823884081882374.post-34281423078791687652011-07-05T12:21:00.000-03:002011-07-05T12:21:17.090-03:00World IPv6 Day recap (techtarget.com)Techtarget.com has published and article entitled "<a href="http://itknowledgeexchange.techtarget.com/wans/world-ipv6-day-recap/">World IPv6 Day recap</a>" which comments on the outcome of the World IPv6 Day.<br />
<br />
I have been quoted in that article noting that many people assume that during the World IPv6 Day, everyone accessed Google and Facebook with IPv6. But that's not the case: most users still accessed those sites with IPv4, since they had no IPv6 connectivity and/or their operating systems preferred IPv4 connectivity over the IPv6 connectivity they had available.<br />
<br />
The full article is available <a href="http://itknowledgeexchange.techtarget.com/wans/world-ipv6-day-recap/">here</a>.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4212823884081882374.post-10923058960464386312011-06-29T02:41:00.000-03:002011-06-29T02:41:42.450-03:00DEEPSEC 2009: Security Assessment of TCP and IPv4<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiVfoJYHMGitgD8YKq3D9A82u3dqadnXz1GOi3eFA6S-huvY4Pt2owBNBLt9A-pS2n-T7hER6n_fumPZdtkreFZjVsZxwdr1E_-l0VIv7-yu7kBr4NHxcOTIDxBEKwk6Q6-bKvHpn-NwhI/s1600/DeepSecLogo.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiVfoJYHMGitgD8YKq3D9A82u3dqadnXz1GOi3eFA6S-huvY4Pt2owBNBLt9A-pS2n-T7hER6n_fumPZdtkreFZjVsZxwdr1E_-l0VIv7-yu7kBr4NHxcOTIDxBEKwk6Q6-bKvHpn-NwhI/s1600/DeepSecLogo.png" /></a></div>The video of a talk I gave in 2009 (!) at <a href="http://www.deepsec.net/">DEEPSEC 2009</a> about some security assessment of TCP and IPv4 that I had carried out on behalf of <a href="http://www.cpni.gov.uk/">CPNI</a> has just been posted by the DEEPSEC folks. The video of the presentation is available <a href="http://vimeo.com/25033253">here</a>. (Note: the slides are available <a href="http://www.gont.com.ar/talks/index.html">here</a>, and the technical reports <a href="http://www.gont.com.ar/papers/index.html">here</a>).Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4212823884081882374.post-14953394743146018622011-06-28T11:17:00.001-03:002011-06-28T14:13:03.773-03:00Hack In Paris 2011: Hacking IPv6 Networks<div class="separator" style="clear: both; text-align: left;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgJH6OhRvz3xRRmfNcwrbomnlkGgxA08Ws2iMFMvzwXSpRlVEjo_Gr0E-ZisFoYgnZQ1V8Kbjv45GqeS7QDCQcnkxkth7Mkv4v-jZp9hWW6JZWwQC_HKCcaXrMTboeT7HeRK4klSgqXZgQ/s1600/hip-logo-png.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgJH6OhRvz3xRRmfNcwrbomnlkGgxA08Ws2iMFMvzwXSpRlVEjo_Gr0E-ZisFoYgnZQ1V8Kbjv45GqeS7QDCQcnkxkth7Mkv4v-jZp9hWW6JZWwQC_HKCcaXrMTboeT7HeRK4klSgqXZgQ/s1600/hip-logo-png.png" /></a>Two weeks ago I travelled to Paris to attend the <a href="http://www.hackinparis.com/">Hack In Paris 2011</a> conference, where I taught the training "Hacking IPv6 Networks". It was a cool experience, in particular because it was possible to do some real IPv6 hacking with some of the attendees (such as testing a stealth IPv6 scanning technique I had envisioned the night before one of the training sessions, while tweaking my slides).</div><br />
I have uploaded the slides used for the aforementioned training, which cover (only) the <u>theory</u> contents of the training. The slides are available <a href="http://www.gont.com.ar/talks/hip2011/fgont-hip2011-hacking-ipv6-networks.pdf">here</a>.<br />
<div style="text-align: left;"></div><span id="goog_1673298431"></span><span id="goog_1673298432"></span>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4212823884081882374.post-18330113451649712552011-06-09T22:15:00.000-03:002011-06-09T22:15:40.564-03:00Lagging IPv6 security features, vulnerabilities could hamper transition<a href="http://searchsecurity.techtarget.com/">SearchSecurity.Techtarget.com</a> has published an <a href="http://searchsecurity.techtarget.com/news/2240036676/Lagging-IPv6-security-features-vulnerabilities-could-hamper-transition">article</a> entitled "<a href="http://searchsecurity.techtarget.com/news/2240036676/Lagging-IPv6-security-features-vulnerabilities-could-hamper-transition">Lagging IPv6 security features, vulnerabilities could hamper transition</a>", authored by Robert Westervelt. The article includes some quotes from an interview I had with Robert.<br />
<br />
Some of the quotes are not verbatim, and thus might be a bit misleading. When in doubt, check <a href="http://www.gont.com.ar/talks/lacnog2010/fgont-lacnog2010-ipv6-security.pdf">these slides</a> from a presentation about IPv6 security I gave last year at <a href="http://www.lacnog.org/en/meetings/lacnog-2010/agenda-lacnog-2010">LACNOG 2010</a>.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4212823884081882374.post-86354860614385757362011-06-08T03:42:00.003-03:002011-07-11T06:11:02.664-03:00RA-Guard Evasion: New revision of my IETF Internet-DraftsI have posted a revision of both of my recently-published IETF Internet-Drafts about RA-Guard evasion:<br />
<br />
<ul><li><i>IPv6 Router Advertisement Guard (RA-Guard) Evasion</i> (<a href="http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-01.txt">draft-gont-v6ops-ra-guard-evasion-01.txt</a>)</li>
</ul><ul><li><i>Security Implications of the Use of IPv6 Extension Headers with IPv6 Neighbor Discovery</i> (<a href="http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-01.txt">draft-gont-6man-nd-extension-headers-01.txt</a>)</li>
</ul><br />
<ul></ul>As always, any comments will be very appreciated.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4212823884081882374.post-45773514746335406192011-06-02T02:39:00.000-03:002011-06-02T02:39:17.644-03:00IPv6 security issues: IPv6 transition mechanismsYet another article that I have authored for <a href="http://searchsecurity.techtarget.com/">searchsecurity.techtarget.com</a>. The "abstract" of the article is:<br />
<br />
<blockquote><i>IPv6, the “new” Internet Protocol, is meant to provide enough addresses to enable virtually unlimited Internet growth in the near future. However, since IPv6 is not backwards compatible with IPv4, a variety of transition/co-existence mechanisms have been devised so the introduction of IPv6 in the IPv4-dominant Internet, and the co-existence of both protocols is facilitated.<br />
<br />
In this tip, we’ll briefly introduce these transition/co-existence mechanisms, and explain why they present a variety of compelling security concerns for enterprises.</i></blockquote><br />
You can find the article online <a href="http://searchsecurity.techtarget.com/tip/IPv6-security-issues-IPv6-transition-mechanisms">here</a>.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4212823884081882374.post-29923153109712080232011-06-02T02:25:00.002-03:002011-06-02T02:29:51.988-03:00Some talks about IPv6 security<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg_4Nl-ebtLEQsltflP5tStYH6r6nXpmFNcy3ixhak8g8fvBYElpNV3Wd23OtcqJldfaDQxeE01B3iblLpGA7YcHYsQcNJpgj89ZaFtlrSRxLayiwEMciHVmgxRpbltROkG6hMKux5VnJk/s1600/fgont-lacnicxv-small.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg_4Nl-ebtLEQsltflP5tStYH6r6nXpmFNcy3ixhak8g8fvBYElpNV3Wd23OtcqJldfaDQxeE01B3iblLpGA7YcHYsQcNJpgj89ZaFtlrSRxLayiwEMciHVmgxRpbltROkG6hMKux5VnJk/s1600/fgont-lacnicxv-small.jpg" /></a></div><div style="text-align: left;"><br />
</div><div style="text-align: left;">During the past few weeks I gave several talks about IPv6 security, at different venues. The first venue was <a href="http://www.lacnic.net/en/eventos/lacnicxv/index.html">LACNIC XV</a>, held in Cancun (Mexico), where I gave a tutorial about IPv6 security, and a presentation about Neighbor Discovery vulnerabilities (the latter in the context of <a href="http://www.lacnic.net/en/eventos/lacnicxv/agenda/lacsec.html">LACSEC 2011</a>).</div><br />
They were followed by two presentations in Arequipa (Peru): one about IPv6 security during <a href="http://conatel.ucsp.edu.pe/">CONATEL 2011</a>, and one about Neighbor Discovery vulnerabilities during the <a href="http://www.ucsp.edu.pe/cisco-conference/index.html">Cisco Academy Conference 2011</a>.<br />
<br />
Finally, I travelled to London (UK), for a workshop about IPv6 transition organized by <a href="http://www.cpni.gov.uk/">CPNI</a>.<br />
<br />
The slides used for these presentations can be found <a href="http://www.gont.com.ar/talks">here</a>.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4212823884081882374.post-417141253010643192011-06-02T02:12:00.000-03:002011-06-02T02:12:33.492-03:00IPv6 myths: Debunking misconceptions regarding IPv6 security featuresAn <a href="http://searchsecurity.techtarget.com/tip/IPv6-myths-Debunking-misconceptions-regarding-IPv6-security-features">article</a> I authored for <a href="http://searchsecurity.techtarget.com/">searchsecurity.techtarget.com</a> has just been published. The articled is entitled "IPv6 myths: Debunking misconceptions regarding IPv6 security features" and discusses a number of myths that have arisen over the years about IPv6 security.<br />
<br />
The article is available online, <a href="http://searchsecurity.techtarget.com/tip/IPv6-myths-Debunking-misconceptions-regarding-IPv6-security-features">here</a>.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4212823884081882374.post-11985088007013869862011-05-31T21:48:00.004-03:002011-06-01T00:09:01.263-03:00Smartphones and location-tracking (Dilbert strip)<div class="separator" style="clear: both; text-align: center;"><a href="http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/100000/20000/0000/600/120690/120690.strip.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="124" src="http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/100000/20000/0000/600/120690/120690.strip.gif" width="400" /></a></div><div class="separator" style="clear: both; text-align: left;"></div><div class="separator" style="clear: both; text-align: left;"><br />
</div><div class="separator" style="clear: both; text-align: left;">Reminds me of the iPhone & Andriod issue that made the news a while ago:</div><ul><li>iPhone: <a href="http://blogs.cisco.com/security/iphone-location-tracking-important-even-if-it-doesnt-matter-to-you/">http://blogs.cisco.com/security/iphone-location-tracking-important-even-if-it-doesnt-matter-to-you/</a></li>
<li>Android: <a href="https://github.com/packetlss/android-locdump">https://github.com/packetlss/android-locdump</a></li>
</ul>P.S.: No need to mention that I'm a DIlbert fan ;-)<br />
<div class="separator" style="clear: both; text-align: left;"><br />
</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4212823884081882374.post-56899375171304219142011-05-31T20:48:00.001-03:002011-05-31T20:51:29.522-03:00RA-Guard evasion and related vulnerabilitiesI've just published two new <a href="http://www.ietf.org/">IETF</a> Internet-Drafts, that document the problem of RA-Guard evasion, and propose mitigations.<br />
<br />
They are two Internet-Drafts:<br />
<ul><li><i>IPv6 Router Advertisement Guard (RA-Guard) Evasion</i>, available at: <a href="http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-00.txt">http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-00.txt</a></li>
<li><i>Security Implications of the Use of IPv6 Extension Headers with IPv6 Neighbor Discovery</i>, available at: <a href="http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-00.txt">http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-00.txt</a></li>
</ul>Any <a href="mailto:fernando@gont.com.ar">comments</a> on these documents will be more than welcome.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4212823884081882374.post-62036824664664629992011-04-06T21:36:00.001-03:002011-04-14T16:50:26.654-03:00RFC 6191: Reducing the TIME-WAIT State Using TCP TimestampsA new <a href="http://www.ietf.org/">IETF</a> RFC that I have authored has been published. It is RFC 6191, entitled "Reducing the TIME-WAIT State Using TCP Timestamps". The Abstract of the RFC is:<br />
<blockquote><i>This document describes an algorithm for processing incoming SYN</i><br />
<i>segments that allows higher connection-establishment rates between</i><br />
<i>any two TCP endpoints when a TCP Timestamps option is present in the</i><br />
<i>incoming SYN segment. This document only modifies processing of SYN</i><br />
<i>segments received for connections in the TIME-WAIT state; processing</i><br />
<i>in all other states is unchanged.</i></blockquote><br />
The RFC is available <a href="http://www.gont.com.ar/rfcs/rfc6191.txt">here</a>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4212823884081882374.post-75446657243464575612011-03-23T01:22:00.000-03:002011-03-23T01:22:24.325-03:00The RSA SecurID ProblemSteven Bellovin posted an analysis of the widely-publicized RSA SecurID issue. His analysis is available <a href="http://www.cs.columbia.edu/%7Esmb/blog//2011-03/2011-03-18.html">here</a>.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4212823884081882374.post-60128520282026676332011-03-23T01:05:00.001-03:002011-03-23T01:11:47.247-03:00Biometric controls (Malaysia car thieves steal finger)From a BBC article:<br />
<br />
<blockquote><i><b>Malaysia car thieves steal finger</b><br />
<br />
Police in Malaysia are hunting for members of a violent gang who chopped off a car owner's finger to get round the vehicle's hi-tech security system.</i></blockquote><br />
The full article is available <a href="http://news.bbc.co.uk/2/hi/asia-pacific/4396831.stm">here</a>.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4212823884081882374.post-90744365487809759762011-02-04T06:25:00.000-03:002011-02-04T06:25:12.600-03:00Software quality (Dilbert comic strip)Dilbert always gets it right: -)<br />
<br />
<div class="separator" style="clear: both; text-align: center;"></div><div class="separator" style="clear: both; text-align: center;"><a href="http://dilbert.com/strips/comic/2011-02-03/"><img border="0" height="99" src="http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/100000/10000/1000/700/111748/111748.strip.gif" width="320" /></a></div><br />
Visit <a href="http://www.dilbert.com/">dilbert.com</a> for more comic strips! ;-)Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4212823884081882374.post-4055023508789322072011-01-21T14:30:00.000-03:002011-01-21T14:30:40.636-03:00Why IPv6 won't rid the Internet of Network Address Translation<a href="http://searchenterprisewan.com/">SearchEnterpriseWAN.com</a> has published an article entitled "Why IPv6 won't rid the Internet of Network Address Translation" that I have authored for them.<br />
<br />
The <a href="http://searchenterprisewan.techtarget.com/tip/Why-IPv6-wont-rid-the-Internet-of-Network-Address-Translation">article</a> begins with:<br />
<br />
<blockquote><i><b>Why IPv6 won't rid the Internet of Network Address Translation</b><br />
<br />
One of the most common myths about IPv6 (Internet Protocol Version 6) is that it will restore the so-called end-to-end principle of the Internet. This article explains how the current ubiquity of Network Address Translation (NAT) across today's enterprise WANs make this very unlikely.</i></blockquote>The full article can be found <a href="http://searchenterprisewan.techtarget.com/tip/Why-IPv6-wont-rid-the-Internet-of-Network-Address-Translation">here</a>. Enjoy!Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4212823884081882374.post-74460516485622916052011-01-21T09:40:00.002-03:002011-02-23T00:05:23.173-03:00Recommendations for Transport-Protocol Port Randomization (IETF RFC 6056)<div style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">Folks,</span><br />
<br />
<span style="font-size: small;">Our document "Recommendations for Transport-Protocol Port Randomization" has just been published as IETF <a href="http://www.rfc-editor.org/rfc/rfc6056.txt">RFC 6056</a>.</span></div><div style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;"><br />
</span></div><span style="font-family: Arial,Helvetica,sans-serif; font-size: small;">The Abstract of the RFC is:</span><br />
<blockquote><pre wrap=""><span style="font-size: small;"><i><span style="font-family: "Courier New",Courier,monospace;">During the last few years, awareness has been raised about a number </span><span style="font-family: "Courier New",Courier,monospace;">of "blind" attacks that can be performed against the Transmission </span><span style="font-family: "Courier New",Courier,monospace;">Control Protocol (TCP) and similar protocols. The consequences of </span><span style="font-family: "Courier New",Courier,monospace;">these attacks range from throughput reduction to broken connections </span><span style="font-family: "Courier New",Courier,monospace;">or data corruption. These attacks rely on the attacker's ability to </span><span style="font-family: "Courier New",Courier,monospace;">guess or know the five-tuple (Protocol, Source Address, Destination </span><span style="font-family: "Courier New",Courier,monospace;">Address, Source Port, Destination Port) that identifies the transport </span><span style="font-family: "Courier New",Courier,monospace;">protocol instance to be attacked. This document describes a number </span><span style="font-family: "Courier New",Courier,monospace;">of simple and efficient methods for the selection of the client port </span><span style="font-family: "Courier New",Courier,monospace;">number, such that the possibility of an attacker guessing the exact </span><span style="font-family: "Courier New",Courier,monospace;">value is reduced. While this is not a replacement for cryptographic </span><span style="font-family: "Courier New",Courier,monospace;">methods for protecting the transport-protocol instance, the </span><span style="font-family: "Courier New",Courier,monospace;">aforementioned port selection algorithms provide improved security </span><span style="font-family: "Courier New",Courier,monospace;">with very little effort and without any key management overhead. The </span><span style="font-family: "Courier New",Courier,monospace;">algorithms described in this document are local policies that may be </span><span style="font-family: "Courier New",Courier,monospace;">incrementally deployed and that do not violate the specifications of </span><span style="font-family: "Courier New",Courier,monospace;">any of the transport protocols that may benefit from them, such as </span><span style="font-family: "Courier New",Courier,monospace;">TCP, UDP, UDP-lite, Stream Control Transmission Protocol (SCTP), </span><span style="font-family: "Courier New",Courier,monospace;">Datagram Congestion Control Protocol (DCCP), and RTP (provided that </span><span style="font-family: "Courier New",Courier,monospace;">the RTP application explicitly signals the RTP and RTCP port </span><span style="font-family: "Courier New",Courier,monospace;">numbers). This memo documents an Internet Best Current Practice.</span></i></span></pre></blockquote><pre wrap=""></pre><pre wrap=""><span style="font-family: Arial,Helvetica,sans-serif; font-size: small;">The RFC is available <a href="http://www.rfc-editor.org/rfc/rfc6056.txt">here</a></span>.</pre>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4212823884081882374.post-41418738545952012072011-01-12T16:52:00.000-03:002011-01-12T16:52:46.071-03:00IPv6 and NATsThis was <a href="http://seclists.org/nanog/2011/Jan/599">posted</a> on the NANOG mailing-list by Jack Bates. Well-said!<br />
<br />
<blockquote><i>As my corp IT guy put it to me, PAT forces a routing disconnect between internal and external. There is no way to reach the hosts without the firewall performing it's NAT function. Given that the internal is exclusively PAT, the DMZ is public with stateful/proxy, this provides protection for the internal network while limiting the dmz exposure.<br />
<br />
The argument everyone makes is that a stateful firewall defaults to deny. However, a single mistake prior to the deny allows traffic in. The only equivalent in a PAT scenario is to screw up port forwarding which would cause a single host to expose a single port unknowingly per mistake (which said port/host combo may not be vulnerable). In a stateful firewall, a screw up could expose all ports on a host or multiple hosts in a single mistake.<br />
<br />
Then there are the firewall software bugs. In PAT, such bugs don't suddenly expose all your hosts behind the firewall for direct communication from the outside world. In v6 stateful firewall, such a bug could allow circumvention of the entire firewall ruleset and the hosts would be directly addressable from the outside.<br />
<br />
PAT offers the smallest of security safeguards. However, many corp IT personnel feel more secure having that small safeguard in place along with the many other safeguards they deploy. In a corporate environment where they often love to break everything and anything, I don't blame them.<br />
<br />
Then we go to the educational sector, where the admins often prefer as much openness as possible. In their case, they will prefer to do away with PAT.<br />
<br />
<br />
Jack</i></blockquote>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4212823884081882374.post-52083997187629236672011-01-07T22:43:00.003-03:002011-01-23T23:11:47.785-03:00Defending Against Sequence Number AttacksWe have published an <a href="http://www.ietf.org/">IETF</a> Internet-Draft entitled "Defending Against Sequence Number Attacks", which is a revision of Steven Bellovin's <a href="http://www.rfc-editor.org/rfc/rfc1948.txt">RFC 1948</a>. The Abstract of the I-D is:<br />
<blockquote><i>This document specifies an algorithm for the generation of TCP Initial Sequence Numbers (ISNs), such that the chances of an off-path attacker of guessing the sequence numbers in use by a target connection are reduced. This document is a revision of RFC 1948, and takes the ISN generation algorithm originally proposed in that document to Standards Track. </i></blockquote>Our I-D is available <a href="http://tools.ietf.org/id/draft-gont-tcpm-rfc1948bis-00.txt">here</a>.<br />
<br />
<br />
<pre wrap=""></pre>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4212823884081882374.post-32397877899361333212011-01-05T00:20:00.001-03:002011-01-21T14:31:51.679-03:00IETF RFC 6093: On the Implementation of the TCP Urgent MechanismRFC 6093 (co-authored by Andrew Yourtchenko and me) has just been published by the RFC Editor.It is available at: <a class="moz-txt-link-freetext" href="http://www.rfc-editor.org/rfc/rfc6093.txt">http://www.rfc-editor.org/rfc/rfc6093.txt</a><br />
<br />
The Abstract of the document is <br />
<br />
<blockquote><i>This document analyzes how current TCP implementations process TCP urgent indications and how the behavior of some widely deployed middleboxes affects how end systems process urgent indications. This document updates the relevant specifications such that they accommodate current practice in processing TCP urgent indications,<br />
raises awareness about the reliability of TCP urgent indications in the Internet, and recommends against the use of urgent indications (but provides advice to applications that do).</i></blockquote>Thanks!Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4212823884081882374.post-82541177938965783072011-01-04T22:14:00.000-03:002011-01-04T22:14:53.231-03:00LACSEC 2011: 6th Network Security Event for Latin America and the Caribbean (Call for Presentations)<pre wrap="">***********************************************************************
CALL FOR PRESENTATIONS
***********************************************************************
LACSEC 2011
6th Network Security Event for Latin America and the Caribbean
May 17-20, 2011, Cancun, Mexico
<a class="moz-txt-link-freetext" href="http://lacnic.net/en/eventos/lacnicxv/index.html">http://lacnic.net/en/eventos/lacnicxv/index.html</a>
LACNIC (<a class="moz-txt-link-freetext" href="http://www.lacnic.net/">http://www.lacnic.net</a>) is the international organization based
in (Uruguay) that is responsible for administrating IP address space,
Reverse Resolution, Autonomous System Numbers and other resources for
the region of Latin America and the Caribbean on behalf of the Internet community.
The “6th Network Security Event for Latin America and the Caribbean”
will be held in Cancun, Mexico, within the framework of LACNIC's
fifteenth annual meeting (LACNIC XV). This is a public call for
presentations for that event.
The topics of interest include, but are not limited to, the following:
* Honeypots, network monitoring and situational awareness tools in general.
* Fighting spam, particularly spam from origin (SPF, DKIM and related technologies. Email reputation)
* Fighting phishing and pharming
* Fighting malware
* Internet protocol security
* IPv6 security
* DNSsec
* Security of network infrastructure services (DNS, NTP, etc.)
* Web security
* DoS/DDoS response and mitigation, botnets
* Authentication and access control
* Security in the cloud
* Protection of critical infrastructure
* Security in mobile systems
* Computer security incident response teams (CSIRTs): creation, management, experiences
* Security in corporate environments, compliance and auditing, return on security investments
* Security management (procedures, operational logs, records, etc.)
* Risk management in Information Security
* Computer forensics
* Protection of privacy
* Legal aspects relating to computer security
Guidelines for Presenting Proposals
Proposals for the “6th Network Security Event for Latin America and the Caribbean” (LACSEC 2011) must be presented taking into account the following considerations:
* The presentation may or may not have one or more accompanying
articles, but the Evaluation Committee may give priority to those that do.
* Proposals may be presented in English, Portuguese or Spanish.
* Proposals must be submitted in Portable Document Format (PDF)
* Submissions must be created directly using a word processing system
(scanned articles will not be accepted)
* Presentations may not be longer than 30 minutes.
Submitting a Proposal
Those interested in presenting at LACSEC 2011 must send the following
information to <a class="moz-txt-link-rfc2396E" href="mailto:comite_seguridad@lacnic.net"><comite_seguridad@lacnic.net></a> within the deadlines set
forth below:
* Full title of the presentation
* Extended abstract and a draft of the slides or the full article if available. The extended abstract should not be longer than one thousand (1000) words. The Evaluation Committee may, at its sole discretion, request additional or complementary information.
* Full name, email address and organization with which the author (or
authors) of the submission is affiliated
For more information, please don't hesitate to contact the Evaluation
Committee at <a class="moz-txt-link-abbreviated" href="mailto:comite_seguridad@lacnic.net">comite_seguridad@lacnic.net</a>.
Proposal Evaluation
The Evaluation Committee that has been created for this purpose will
evaluate proposals based on the following basic criteria:
* Originality
* Technical quality
* Relevance
* Presentation
* Applicability
IMPORTANT DATES
* Deadline for proposal reception: March 4th, 2011
* Notification of acceptance: March 14th, 2011
* Deadline for submitting the final version the presentation: May 9th, 2011
“6th Network Security Event for Latin America and the Caribbean” (LACSEC 2011)
Chair
Fernando Gont (UTN/FRH, Argentina)
Evaluation Committee
Eduardo Carozo (Amparo Project, Uruguay)
Lorena Ferreyro (Independent consultant, Argentina)
Javier Liendo (Cisco, Mexico)
Fernando Maresca (ONTI, Argentina)
Carlos Martinez Cagnazzo (LACNIC, Uruguay)
Domingo Montanaro (iSight Partners, Brazil)
Jose Miguel Parrella Romero (Debian developer, Ecuador)
Patricia Prandini (ADACSI, Argentina)
Juliano Rizzo (Netifera, Argentina)
Javier Romero (JaCkSecurity, Peru)
Arturo Servin (LACNIC, Uruguay)
Liliana V. Solha (CAIS/RNP, Brazil)
Lisandro Teszkiewicz (Independent consultant, Argentina)
Leonardo Vidal (ISOC Uruguay Chapter, Uruguay)
</pre>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-4212823884081882374.post-86103047905414717172010-12-28T15:41:00.001-03:002010-12-29T11:52:02.850-03:00Does Cisco really eat its own IPv6 dog food?While the <a href="http://www.networkworld.com/news/2010/092810-cisco-ipv6.html">article</a> written by Carolyn Duffy Marsan for NetworkWorld is entitled "Cisco eats its own IPv6 dog food", this excerpt does not really indicate that Cisco is <i>really</i> eating its own dogfood:<br />
<br />
<blockquote><i>Cisco confirmed Tuesday that on Aug. 23 it began testing IPv6 on an alternative Web site -- www.ipv6.cisco.com -- instead of its main Web site, which is www.cisco.com. Cisco said it is maintaining a dual IPv6 and IPv4 approach for its external Web presence so that all of its customers can access the Web site reliably.</i></blockquote> Full article <a href="http://www.networkworld.com/news/2010/092810-cisco-ipv6.html">here</a>.Unknownnoreply@blogger.com0