<html><body><div style="color:#000; background-color:#fff; font-family:Helvetica Neue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;font-size:16px"><div><span>Hi Warren,</span></div><br> <div id="yui_3_16_0_1_1434762512153_4103"> <div id="yui_3_16_0_1_1434762512153_4102"> <div dir="ltr" id="yui_3_16_0_1_1434762512153_4101" style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 16px;"> <hr size="1"> <font size="2" face="Arial" id="yui_3_16_0_1_1434762512153_4104"> <b><span style="font-weight:bold;">From:</span></b> Warren Kumari <warren@kumari.net><br> <b><span style="font-weight: bold;">To:</span></b> Mark ZZZ Smith <markzzzsmith@yahoo.com.au> <br><b><span style="font-weight: bold;">Cc:</span></b> Enno Rey <erey@ernw.de>; Ole Troan <otroan@employees.org>; "v6ops@ietf.org" <v6ops@ietf.org>; "ipv6-wg@ripe.net" <ipv6-wg@ripe.net> <br> <b><span style="font-weight: bold;">Sent:</span></b> Saturday, 20 June 2015, 6:19<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices<br> </font> </div> <div class="y_msg_container" id="yui_3_16_0_1_1434762512153_4105" style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 16px;"><br>On Fri, Jun 19, 2015 at 5:13 AM, Mark ZZZ Smith<br clear="none"><<a shape="rect" ymailto="mailto:markzzzsmith@yahoo.com.au" href="mailto:markzzzsmith@yahoo.com.au">markzzzsmith@yahoo.com.au</a>> wrote:<br clear="none">><br clear="none">> ________________________________<br clear="none">> From: Enno Rey <<a shape="rect" ymailto="mailto:erey@ernw.de" href="mailto:erey@ernw.de">erey@ernw.de</a>><br clear="none">> To: Ole Troan <<a shape="rect" ymailto="mailto:otroan@employees.org" href="mailto:otroan@employees.org">otroan@employees.org</a>><br clear="none">> Cc: <a shape="rect" ymailto="mailto:v6ops@ietf.org" href="mailto:v6ops@ietf.org" id="yui_3_16_0_1_1434762512153_4336">v6ops@ietf.org</a>; <a shape="rect" ymailto="mailto:ipv6-wg@ripe.net" href="mailto:ipv6-wg@ripe.net">ipv6-wg@ripe.net</a><br clear="none">> Sent: Friday, 19 June 2015, 18:34<br clear="none">> Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security<br clear="none">> Devices<br clear="none">><br clear="none"><snip></div><div class="y_msg_container" id="yui_3_16_0_1_1434762512153_4105" style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 16px;"><br clear="none">><br clear="none">> / I think you're only expressing the view of many security engineers, not<br clear="none">> the many network engineers or the many more users of networks. At an ISP, if<br clear="none">> you block traffic your customer wants send, all you get is angry customers.<br clear="none"><br clear="none">... and at an ISP if your customer calls you up because they are being<br clear="none">DDoSed out of existence with traffic at some port that they don't use,<br clear="none">and you tell them at that you cannot filter UDP port 80 because, well,<br clear="none">you cannot find it, you also end up with an angry customer.</div><div class="y_msg_container" id="yui_3_16_0_1_1434762512153_4105" style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 16px;"><br></div><div class="y_msg_container" id="yui_3_16_0_1_1434762512153_4105" style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 16px;">/ If you can't find it, that may be because it isn't actually there.</div><div class="y_msg_container" id="yui_3_16_0_1_1434762512153_4105" style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 16px;"><br></div><div class="y_msg_container" id="yui_3_16_0_1_1434762512153_4105" style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 16px;">/ Here's what I wrote in my earlier email what problem/problems being solved email about network capacity DoS:</div><div class="y_msg_container" id="yui_3_16_0_1_1434762512153_4105" style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 16px;"><br></div><div class="y_msg_container" id="yui_3_16_0_1_1434762512153_4105" dir="ltr"><font face="HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif" class="" style="" id="yui_3_16_0_1_1434762512153_5302">/ "(1) I think TCP/UDP port level filtering for this purpose is certainly a nice to have but not a necessary to have, because network capacity DoSs will use some other protocol for their DoS if mitigating DoSs using TCP/UDP traffic becomes too effective. Completely dropping DoS traffic identified just by src and/or dst address, or plonking that traffic into a scavenger QoS class for a while if complete dropping is too severe is a general solution that will work regardless of the type of DoS traffic. Using TCP/UDP ports if they're easily available would allow the dropping to be more granular, but is not required to mitigate the network capacity DoS."</font><br></div><div class="y_msg_container" id="yui_3_16_0_1_1434762512153_4105" style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 16px;"><br></div><div class="y_msg_container" id="yui_3_16_0_1_1434762512153_4105" style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 16px;" dir="ltr">/ although I'd reword that last sentence and say something like "Using TCP/UDP ports if they're easily available would allow the dropping to be more granular, but cannot be relied on to mitigate all network capacity DoSes."</div><div class="y_msg_container" id="yui_3_16_0_1_1434762512153_4105" style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 16px;"><br></div><div class="y_msg_container" id="yui_3_16_0_1_1434762512153_4105" style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 16px;">/ If the motivation of the DoS attacker is to exhaust network capacity, then they don't really care what type of traffic it is. Using UDP or TCP is probably convenient, but if that becomes too easy to block, they'll use something else.</div><div class="y_msg_container" id="yui_3_16_0_1_1434762512153_4105" style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 16px;"><br></div><div class="y_msg_container" id="yui_3_16_0_1_1434762512153_4105" style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 16px;" dir="ltr">/ OTOH, if their motivation is to DoS a particular application, then you're going to have to let some of it through because some of it is legitimate via something like the policed/shaped QoS class, as well as possibly by dropping traffic from a set of sources that appear to be DoS traffic origins rather than legitimate sources.</div><div class="y_msg_container" id="yui_3_16_0_1_1434762512153_4105" style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 16px;" dir="ltr"><br></div><div class="y_msg_container" id="yui_3_16_0_1_1434762512153_4105" style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 16px;" dir="ltr">/ Perhaps wanting the TCP and UDP headers in a known location in the packet so that simple ACLs can filter them is a more specific case of being able to filter packets using a bit mask in an arbitrary specified location within the packet. I'm not aware of any routers where this is an option in ACLs (although it is ringing a very small bell), so perhaps that is what is missing from routers today (I don't know much about OpenFlow, although I'd have expected OF switches to be able to do this. However, quickly downloading and looking at the OF specs, it doesn't seem that specifying an arbitrary bit range and mask to match on is supported). Being able to do that would not only make ACLs more general purpose, but would also allow more accurate filtering on non-TCP/UDP packets too, rather than just using source and/or destination addresses for this traffic. I think that would better alleviate the desire of people to restrict transport layer protocols to only TCP/UDP.</div><div class="y_msg_container" id="yui_3_16_0_1_1434762512153_4105" style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 16px;" dir="ltr"><br></div><div class="y_msg_container" id="yui_3_16_0_1_1434762512153_4105" style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 16px;" dir="ltr">/ A DoS attacker could overcome that by randomising packet contents, however that is more work for them, and I think would classify the DoS attack as a network capacity exhaustion attack, meaning that the methods such as dropping or policing/shaping high volume sources using just IP addresses would be more effective.</div><div class="y_msg_container" id="yui_3_16_0_1_1434762512153_4105" style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 16px;"><br clear="none"><br clear="none">> They're paying you to deliver any and all of their packets as well as<br clear="none">> possible, with as minimum restrictions as possible, ideally none, rather<br clear="none">> than the opposite.<br clear="none"><br clear="none">Perhaps. I figure they are /actually/ paying you to provide them with<br clear="none">good service. Sometimes that includes filtering for them, because you<br clear="none">have bigger pipes than them...</div><div class="y_msg_container" id="yui_3_16_0_1_1434762512153_4105" style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 16px;"><br></div><div class="y_msg_container" id="yui_3_16_0_1_1434762512153_4105" style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 16px;" dir="ltr">/ I think sanitising traffic is a different and much harder problem to solve than mitigating a DoS attack. I think mitigating DoSes is enough of a service to provide to customers as part of their Internet access, because going any "deeper" means getting involved in what protocols and therefore what applications the customer is choosing to use and may choose to use in the future. That's a separate service.</div><div class="y_msg_container" id="yui_3_16_0_1_1434762512153_4105" style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 16px;" dir="ltr"><br></div><div class="y_msg_container" id="yui_3_16_0_1_1434762512153_4105" style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 16px;" dir="ltr">/ Regards,</div><div class="y_msg_container" id="yui_3_16_0_1_1434762512153_4105" style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 16px;" dir="ltr">/ Mark.</div><div class="y_msg_container" id="yui_3_16_0_1_1434762512153_4105" style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 16px;"><br clear="none"><br clear="none">W<br clear="none"><br clear="none">> This is why I don't think you'll ever get consensus on<br clear="none">> deprecating EHs, because I think you're only coming the position of trying<br clear="none">> to solve problem (3) I described in my last email.<br clear="none">><br clear="none">> / I'd also observe that deprecating EHs, other than ESP, AH+FH, TCP and UDP,<br clear="none">> would also prevent them from being used behind the ESP EH - where you won't<br clear="none">> be able to see what is in them, so you won't be able to care what is in<br clear="none">> them. You'll also be preventing people from other transport layer protocols,<br clear="none">> such as SCTP and DCCP, that are feasible to deploy over the IPv6 Internet<br clear="none">> that couldn't be over the IPv4 network because of IPv4 NAT and other middle<br clear="none">> boxes.<br clear="none">><br clear="none">> thanks<br clear="none">><br clear="none">> Enno<br clear="none">><br clear="none">><br clear="none">><br clear="none">><br clear="none">>><br clear="none">>> cheers,<br clear="none">>> Ole<br clear="none">><br clear="none">><br clear="none">><br clear="none">> --<br clear="none">> Enno Rey<br clear="none">><br clear="none">> ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de<br clear="none">> Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902<br clear="none">><br clear="none">> Handelsregister Mannheim: HRB 337135<br clear="none">> Geschaeftsfuehrer: Enno Rey<br clear="none">><br clear="none">> =======================================================<br clear="none">> Blog: || Conference: www.troopers.de<div class="qtdSeparateBR"><br><br></div><div class="yqt0213232052" id="yqtfd30757"><br clear="none">> Twitter: @Enno_Insinuator<br clear="none">><br clear="none">><br clear="none">><br clear="none">> =======================================================<br clear="none">><br clear="none">> _______________________________________________<br clear="none">> v6ops mailing list<br clear="none">> <a shape="rect" ymailto="mailto:v6ops@ietf.org" href="mailto:v6ops@ietf.org">v6ops@ietf.org</a><br clear="none">> <a shape="rect" href="https://www.ietf.org/mailman/listinfo/v6ops" target="_blank">https://www.ietf.org/mailman/listinfo/v6ops</a><br clear="none">><br clear="none">><br clear="none">><br clear="none">> _______________________________________________<br clear="none">> v6ops mailing list<br clear="none">> <a shape="rect" ymailto="mailto:v6ops@ietf.org" href="mailto:v6ops@ietf.org">v6ops@ietf.org</a><br clear="none">> <a shape="rect" href="https://www.ietf.org/mailman/listinfo/v6ops" target="_blank">https://www.ietf.org/mailman/listinfo/v6ops</a></div><br clear="none">><br clear="none"><br clear="none"><br clear="none"><br clear="none">-- <br clear="none">I don't think the execution is relevant when it was obviously a bad<br clear="none">idea in the first place.<br clear="none">This is like putting rabid weasels in your pants, and later expressing<br clear="none">regret at having chosen those particular rabid weasels and that pair<br clear="none">of pants.<br clear="none"> ---maf<div class="yqt0213232052" id="yqtfd09224"><br clear="none"></div><br><br></div> </div> </div> </div></body></html>