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

From: Ole Troan <[email-masked]>
Date: Fri, 23 Aug 2013 09:55:53 +0200

All,

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.

Regards,

Bob Hinden & Ole Trøan

---

From: Simon Perreault <[email-masked]>
Date: Wed, 28 Aug 2013 11:46:37 +0200

> 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

---

From: Tina TSOU <[email-masked]>
Date: Wed, 28 Aug 2013 17:16:48 +0000

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:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Stig Venaas <[email-masked]>
Date: Wed, 28 Aug 2013 10:38:12 -0700

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

---

From: Fernando Gont <[email-masked]>
Date: Fri, 30 Aug 2013 22:57:33 -0300

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