Re: 6MAN Adoption call on draft-gont-6man-ipv6-smurf-amplifier-03
After reviewing the adoption call comments, the chairs have decided not to adopt draft-gont-ipv6-smurf-amplifier. - We have not seen strong working group support for working on the draft. - We are not convinced that the problem the draft sets out to resolve is worth fixing given that multicast RPF checking eliminates the vast majority of the attack vector. Best regards, Bob Ole All, This message starts a one week 6MAN Working Group call on adopting: Title : Security Implications of IPv6 Options of Type 10xx Author(s): F. Gont, W. Liu Filename: draft-gont-6man-ipv6-smurf-amplifier-03 Pages: 12 Date : 2013-03-21 http://tools.ietf.org/html/draft-gont-6man-ipv6-smurf-amplifier-03 The call ends on August 30th, 2013. Regards, Bob Hinden Ole Trøan IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 signature.asc Description: Message signed with OpenPGP using GPGMail IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: 6MAN Adoption call on draft-gont-6man-ipv6-smurf-amplifier-03
Fernando, would that be other nodes than yourself and nodes on the same link as yourself? I guess in some scenarios it might be tricky. For instance, even with link-local only multicast (as that used for ND), you can send a packet to a link-local multiast address, but sourced from any global address. Hence you can have your own network be an amplifier to attack a third party. yes, but there are many other ways of doing that, and e.g. ping ff02::1 with victims source address would be a lot more effective. Not to mention that if you're employing e.g. an openvpn Ethernet bridge, it becomes fuzzy what's your local link (i.e. real links vs. virtual link). a virtual link is as good as any other in this context. IMO, this is the kind of feature that's asking for trouble. IMHO, let's fix it, and move on. I for one would like to see attack vectors outside the local link before supporting adopting this document. cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: 6MAN Adoption call on draft-gont-6man-ipv6-smurf-amplifier-03
It's a bit late for the call on adoption, but FWIW I support Fernando. Tom Taylor On 03/09/2013 8:44 PM, Fernando Gont wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/02/2013 07:34 AM, Ole Troan wrote: If you read chapter 5 it starts out by explaining how RPF check is always done for multicast. Due to the RPF check, the possibility of spoofing is significantly reduced. Just like it is when using unicast RPF. Hence I don't think this attack vector is that serious. That might help preventing an attacker to exploit this against an arbitrary system, but not against all nodes. would that be other nodes than yourself and nodes on the same link as yourself? I guess in some scenarios it might be tricky. For instance, even with link-local only multicast (as that used for ND), you can send a packet to a link-local multiast address, but sourced from any global address. Hence you can have your own network be an amplifier to attack a third party. Not to mention that if you're employing e.g. an openvpn Ethernet bridge, it becomes fuzzy what's your local link (i.e. real links vs. virtual link). IMO, this is the kind of feature that's asking for trouble. IMHO, let's fix it, and move on. Cheers, - -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJSJoIzAAoJEK4lDVUdTnSSorIP/jMn8htTnIsFa8hjzV56WbV+ tORPAy4IcjHhqDm28GbQzFO29T3JpfkKbhI/RGk5AD1s6A9rKIhBH6JciMSoU1+z lB8Cnv+d4yyrekI2bj4T0tSM0rINYTmDD2PhrpPSs0zCSoLffimybISuOBld1B03 V8HEcVom8p7LWWaz6d6flO10Qxg2W/VtO1RRGFHER0OBRLjriKjfijSBaNWl1m9h 3JrgoFjylNmmBZSQPaP1URHnUx/n8wMzEiAG7Oc0uHU8l1XQQFjpIYWwc58jCOds tIPUqLr60RsMNkJwd1YCmFWWws8tl8a3AVswLsEBXg+w2t8jfXIy2lT4Gkwo+VKx kAhaXg6Dg/x4KhCAnqrUet3kqmTyOYIu6n2MbbGrlz4pvyH4U7SiNQPGJI7/yrLg CQIJU4TSUAHR0ypan3oWVDmop4tnZe1jfxcUFqmeWtQ5IEBhwy5wmzKfDIwYcDe2 cS080uJx/s9eIyQtjCWD1aNSXNo5T06zbX0VLzc50LGDmWmH30PyrZDcYdW/Ig8x SrYpv/mCXJW+C3LOUGsLetoFsnmFK1QcfzAQ9Vka4BLGnd5Em3+zZBzFSsQdPHMP qrmFQnIYWEjc31n9VifLOlXU4cf9fa2isaR+KWDpUXkD2B42KwEMtGi9KAZre9tQ pRJVmtQE6Azhntlh6otb =pTp6 -END PGP SIGNATURE- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: 6MAN Adoption call on draft-gont-6man-ipv6-smurf-amplifier-03
Hi On 9/4/2013 4:28 AM, Ole Troan wrote: Fernando, would that be other nodes than yourself and nodes on the same link as yourself? I guess in some scenarios it might be tricky. For instance, even with link-local only multicast (as that used for ND), you can send a packet to a link-local multiast address, but sourced from any global address. Hence you can have your own network be an amplifier to attack a third party. yes, but there are many other ways of doing that, and e.g. ping ff02::1 with victims source address would be a lot more effective. Not to mention that if you're employing e.g. an openvpn Ethernet bridge, it becomes fuzzy what's your local link (i.e. real links vs. virtual link). a virtual link is as good as any other in this context. IMO, this is the kind of feature that's asking for trouble. IMHO, let's fix it, and move on. I for one would like to see attack vectors outside the local link before supporting adopting this document. That is also my opinion. It seems to me that we are not really removing any attack vector by making this change. As Ole mentioned, there are other easy ways of doing the same attack from your own network. Also, I view that as less serious since it can easily be tracked. Stig cheers, Ole IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: 6MAN Adoption call on draft-gont-6man-ipv6-smurf-amplifier-03
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/02/2013 07:34 AM, Ole Troan wrote: If you read chapter 5 it starts out by explaining how RPF check is always done for multicast. Due to the RPF check, the possibility of spoofing is significantly reduced. Just like it is when using unicast RPF. Hence I don't think this attack vector is that serious. That might help preventing an attacker to exploit this against an arbitrary system, but not against all nodes. would that be other nodes than yourself and nodes on the same link as yourself? I guess in some scenarios it might be tricky. For instance, even with link-local only multicast (as that used for ND), you can send a packet to a link-local multiast address, but sourced from any global address. Hence you can have your own network be an amplifier to attack a third party. Not to mention that if you're employing e.g. an openvpn Ethernet bridge, it becomes fuzzy what's your local link (i.e. real links vs. virtual link). IMO, this is the kind of feature that's asking for trouble. IMHO, let's fix it, and move on. Cheers, - -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJSJoIzAAoJEK4lDVUdTnSSorIP/jMn8htTnIsFa8hjzV56WbV+ tORPAy4IcjHhqDm28GbQzFO29T3JpfkKbhI/RGk5AD1s6A9rKIhBH6JciMSoU1+z lB8Cnv+d4yyrekI2bj4T0tSM0rINYTmDD2PhrpPSs0zCSoLffimybISuOBld1B03 V8HEcVom8p7LWWaz6d6flO10Qxg2W/VtO1RRGFHER0OBRLjriKjfijSBaNWl1m9h 3JrgoFjylNmmBZSQPaP1URHnUx/n8wMzEiAG7Oc0uHU8l1XQQFjpIYWwc58jCOds tIPUqLr60RsMNkJwd1YCmFWWws8tl8a3AVswLsEBXg+w2t8jfXIy2lT4Gkwo+VKx kAhaXg6Dg/x4KhCAnqrUet3kqmTyOYIu6n2MbbGrlz4pvyH4U7SiNQPGJI7/yrLg CQIJU4TSUAHR0ypan3oWVDmop4tnZe1jfxcUFqmeWtQ5IEBhwy5wmzKfDIwYcDe2 cS080uJx/s9eIyQtjCWD1aNSXNo5T06zbX0VLzc50LGDmWmH30PyrZDcYdW/Ig8x SrYpv/mCXJW+C3LOUGsLetoFsnmFK1QcfzAQ9Vka4BLGnd5Em3+zZBzFSsQdPHMP qrmFQnIYWEjc31n9VifLOlXU4cf9fa2isaR+KWDpUXkD2B42KwEMtGi9KAZre9tQ pRJVmtQE6Azhntlh6otb =pTp6 -END PGP SIGNATURE- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: 6MAN Adoption call on draft-gont-6man-ipv6-smurf-amplifier-03
Fernando, I'm not sure if this attack is all that serious since there is always an RPF check for multicast. As it says in the draft: It should be noted that if the multicast RPF check is used (e.g. to prevent routing loops), this would prevent an attacker from forging the Source Address of a packet to an arbitrary value, thus preventing an attacker from launching this attack against a remote network. Chapter 5 of [Juniper2010] discusses multicast RPF configuration for Juniper routers. If you read chapter 5 it starts out by explaining how RPF check is always done for multicast. Due to the RPF check, the possibility of spoofing is significantly reduced. Just like it is when using unicast RPF. Hence I don't think this attack vector is that serious. That might help preventing an attacker to exploit this against an arbitrary system, but not against all nodes. would that be other nodes than yourself and nodes on the same link as yourself? cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: 6MAN Adoption call on draft-gont-6man-ipv6-smurf-amplifier-03
Resending as the IETF list had some drops the last few days. -Vishwas On Wed, Aug 28, 2013 at 4:37 PM, Vishwas Manral vishwas.i...@gmail.comwrote: Hi folks, I have read the document. I see the issue recognized as a genuine gap. I would love to see the document through, also look more deeply into the IPv6 specification to see if other similar issues exist. Thanks, Vishwas On Wed, Aug 28, 2013 at 10:16 AM, Tina TSOU tina.tsou.zout...@huawei.comwrote: Dear all, I have read draft-gont-6man-ipv6-smurf-amplifier-03 and believe the security implications discussed and the suggestions for updating the two RFCs are essential for security considerations, and the operational mitigations proposed in the document provide good choices for design. I support the adoption of this document as a WG document. Thank you, Tina On Aug 28, 2013, at 2:47 AM, Simon Perreault simon.perrea...@viagenie.ca wrote: Le 2013-08-23 09:55, Ole Troan a écrit : This message starts a one week 6MAN Working Group call on adopting: Title : Security Implications of IPv6 Options of Type 10xx Author(s): F. Gont, W. Liu Filename: draft-gont-6man-ipv6-smurf-amplifier-03 Pages: 12 Date : 2013-03-21 http://tools.ietf.org/html/draft-gont-6man-ipv6-smurf-amplifier-03 The call ends on August 30th, 2013. For adoption. I had commented on this draft earlier. I just read it again and still find it useful. I think we should simplify the recommendations and just never send Parameter Problem errors to multicast addresses. That's how it's going to be implemented in practice anyway. By the way, there seems to be an editing mistake on page 6, item (e.3) is repeated. Simon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: 6MAN Adoption call on draft-gont-6man-ipv6-smurf-amplifier-03
On 08/28/2013 02:38 PM, Stig Venaas wrote: I'm not sure if this attack is all that serious since there is always an RPF check for multicast. As it says in the draft: It should be noted that if the multicast RPF check is used (e.g. to prevent routing loops), this would prevent an attacker from forging the Source Address of a packet to an arbitrary value, thus preventing an attacker from launching this attack against a remote network. Chapter 5 of [Juniper2010] discusses multicast RPF configuration for Juniper routers. If you read chapter 5 it starts out by explaining how RPF check is always done for multicast. Due to the RPF check, the possibility of spoofing is significantly reduced. Just like it is when using unicast RPF. Hence I don't think this attack vector is that serious. That might help preventing an attacker to exploit this against an arbitrary system, but not against all nodes. Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: 6MAN Adoption call on draft-gont-6man-ipv6-smurf-amplifier-03
Dear all, I have read draft-gont-6man-ipv6-smurf-amplifier-03 and believe the security implications discussed and the suggestions for updating the two RFCs are essential for security considerations, and the operational mitigations proposed in the document provide good choices for design. I support the adoption of this document as a WG document. Thank you, Tina On Aug 28, 2013, at 2:47 AM, Simon Perreault simon.perrea...@viagenie.ca wrote: Le 2013-08-23 09:55, Ole Troan a écrit : This message starts a one week 6MAN Working Group call on adopting: Title : Security Implications of IPv6 Options of Type 10xx Author(s): F. Gont, W. Liu Filename: draft-gont-6man-ipv6-smurf-amplifier-03 Pages: 12 Date : 2013-03-21 http://tools.ietf.org/html/draft-gont-6man-ipv6-smurf-amplifier-03 The call ends on August 30th, 2013. For adoption. I had commented on this draft earlier. I just read it again and still find it useful. I think we should simplify the recommendations and just never send Parameter Problem errors to multicast addresses. That's how it's going to be implemented in practice anyway. By the way, there seems to be an editing mistake on page 6, item (e.3) is repeated. Simon IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: 6MAN Adoption call on draft-gont-6man-ipv6-smurf-amplifier-03
Hi I'm not sure if this attack is all that serious since there is always an RPF check for multicast. As it says in the draft: It should be noted that if the multicast RPF check is used (e.g. to prevent routing loops), this would prevent an attacker from forging the Source Address of a packet to an arbitrary value, thus preventing an attacker from launching this attack against a remote network. Chapter 5 of [Juniper2010] discusses multicast RPF configuration for Juniper routers. If you read chapter 5 it starts out by explaining how RPF check is always done for multicast. Due to the RPF check, the possibility of spoofing is significantly reduced. Just like it is when using unicast RPF. Hence I don't think this attack vector is that serious. Unless I'm missing something, I don't think it is worth making the proposed change. Stig IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
