Subject: Re: 6MAN Adoption call on <draft-gont-6man-ipv6-smurf-amplifier-03>

From: Vishwas Manral <[email-masked]>
Date: Sun, 1 Sep 2013 21:31:55 -0700

Resending as the IETF list had some drops the last few days.

-Vishwas

On Wed, Aug 28, 2013 at 4:37 PM, Vishwas Manral <[email-masked]>wrote:

> 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 <[email-masked]>wrote:
>
>> 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" <
>> [email-masked]> 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
>> 10xxxxxx
>> >>    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
>> > [email-masked]
>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> > --------------------------------------------------------------------
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [email-masked]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>
>

---

From: Ole Troan <[email-masked]>
Date: Mon, 2 Sep 2013 12:34:56 +0200

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

---

From: Fernando Gont <[email-masked]>
Date: Tue, 03 Sep 2013 21:44:07 -0300

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.
> 

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: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Ole Troan <[email-masked]>
Date: Wed, 4 Sep 2013 13:28:42 +0200

Fernando,

> 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.

> bridge, it becomes fuzzy what's your local link (i.e. real links vs.

a virtual link is as good as any other in this context.

> 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

---

From: Tom Taylor <[email-masked]>
Date: Wed, 04 Sep 2013 11:22:06 -0400

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
>
> -----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-----

---

From: Stig Venaas <[email-masked]>
Date: Wed, 04 Sep 2013 11:38:00 -0700

Hi

> 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

---

From: Ole Troan <[email-masked]>
Date: Tue, 24 Sep 2013 20:52:34 +0200

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,
> 	Title           : Security Implications of IPv6 Options of Type 10xxxxxx
> Regards,
> Bob Hinden & Ole Trøan