[ipv6hackers] Antonio's course slideware

[Fernando Gont]

Hi, Antonio,

As a result of Enno's heads-up on your scanner, I ended u looking at
your slideware.

First of all, congrats for the good material (very-very detailed info on
Extension Headers), and for sharing in the first place -- sharing helps
to advance the field.

Some comments/feedback:

* On slide 76 (about RA-Guard):

There are two (kind of) orthogonal mitigations:

1) RFC 6980 -- which, by banning fragmentation for Neighbor Discovery,
allows ND packet inspection, etc.

2) draft-ietf-v6ops-ra-guard-implementation -- recommends how to
implement RA-Guard to prevent evasion.

"2)" stands on drft-ietf-6man-oversized-header-chain, which one would
expect to see published as an RFC soon.


* Page 79 (regarding filtering EHs and fragmentation):

At the very least, I wouldn't filter IPv6 fragments.


* Page 84 (discussion of draft-ietf-6man-oversized-header-chain):

Such pathological fragments do more harm than any possible potential
benefit, by preventing stateless processing of packets

That said -- and as noted by the slideware/presentation I recently gave
at IEPG, you should consider yourself lucky if you can get a "looks
legitimate" packet with EH to a destination node.

We have all seen the pathological packets as a bug in the spec rather
than as an intended "feature".


* Page 93 (how packets are reassembled)

This is misleading or incorrect -- headers corresponding to the
unfragmentable part can be contained in non-zero FO packets (think about
oversized header chains).


* Page 94: "(does this mean that there
shouldn't be fragments smaller than 1280 bytes?)"

There could be fragments smaller than 1280 bytes -- e.g., an orginal
packet could be fragmented in equally-sized pieces. (not to mention
last-fragments, which will typically be smaller than 1280 bytes).


* Page 103 (discussion on fragment sizes): "Hence, all major OS accept
fragments as small as 56
bytes (including IPv6 header = 40 bytes IPv6 Header +
8 bytes Fragment Header + 8 bytes IPv6 payload).
"

The problem is not the fragment size, but rather situations such as
draft-ietf-6man-oversized-header-chain, which are mostly irrespective of
the fragment size.


* Slide 116 (Assessing the Frag ID policy)

Use the frag6 tool with the "frag-id-policy" option. ;-)


* Slide 146:
Discarding subsequent fragments would tie system resources unnecessarily
(you need to keep record of fragments you may need to drop in th future).


* Slide 150: "It uses different queues for atomic fragments,
but: Although it doesn't consider them as overlapping
fragments, it doesn't respond to them."

Could you please elaborate?


* Page 157: "When the overlapped fragment is an atomic one,
two responses are sent back, showing the
implementation of different queues for them."

mm... I don't follow -- if a fragment is atomic, it can't possibly
overlap...


* Slide 180: "If no, (because of not-predicting Fragment ID numbers),
why the atomic should be handled differently (RFC 6946)?

Because, by definition, an atomic fragment does not need of any other
packet for it to be processed.


* Slide 187: THC-IPv6 and IPv6 toolkit (SI6-IPv6) complement each other.
THC-IPv6 has attack-specific tools, while SI6-IPv6 has flexible tools.
scan6 of SI6-IPv6 is probably the most complete IPv6 address scanner,
but there's no equivalent to THC-IPv6's dnsrevenum6 in SI6-IPv6, etc....


* Slide 186: The IPv6 toolkit was created *specifically* for this
reason: flexibility and portability in mind. ;-)

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492