[ipv6hackers] Antonio's course slideware

[Antonios Atlasis]

Hi Fenando,

thanks a lot for your valuable feeback. I really appreciate it.


2013/11/11 Fernando Gont <fgont at si6networks.com>

> ...
>
>
> * Page 79 (regarding filtering EHs and fragmentation):
>
> At the very least, I wouldn't filter IPv6 fragments.
>
> I agree. I just wanted to raise the question and to trigger a discussion.
This is why in the preceding bullet I say that "should be considered only
as temporary ones, since they actually suppress some of the IPv6 added
functionality". One of the topics that we have discussed extensively with
Enno.

>
> * 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".
>
>
>
Again, I do not necessarily disagree with you, I definitely get your points
and your arguments, I just wanted to start a discussion. To be honest,
although I do agree that should be very very unrare to see such chains and
that they would cause more problems than they would offer benefits, I like
to have the other option still open: Can we somehow do both? Can we "solve"
the security issues while preserving this "feature"? Just an issue for
discussion for me.



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

These are quotes from RFC 2460, page 22 and not my observations. It is one
of the several RFC recommendations that seemed "weird" to me. This is
exactly one of my points!



>
>
> * 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).
>
>
>
First of all, the last fragment is a very special case and its payload can
definitely be as small as 8 bytes or perhaps even smaller, since it is the
last part of the original unfragmentable part that it remains. So, the
question was not about the last fragment. Secondly, once more I raised a
question because according to the RFC 2460:

"On any link that cannot convey a 1280-octet packet in one piece,
link-specific fragmentation and reassembly MUST be provided at a layer
below IPv6."

Perhaps I am wrong, but I would interpret this recommendation as that you
shouldn't expect to see tiny IPv6 fragments except of course from the last
one.  Hence, one more topic for discussion for me.



> * 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.
>
>
I agree that the problem is not the fragment size, but the combination of
several issues. During the class I pointed out clearly many times that it
is the combination of issues that may give you a vulnerability. I
understand that it is not easy to get the whole and precise picture just
from the slides.


>
> * Slide 116 (Assessing the Frag ID policy)
>
> Use the frag6 tool with the "frag-id-policy" option. ;-)
>

I 'll have that in mind. As I can tell from the supported features, your
tool is fantastic! Both you and Marc have done an excellent job! Congrats!



>
>
> * 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).
>
>
Once again, I agree. I also like the FreeBSD way more than the RFC5722 way.
We have also discussed this with Enno. Given this opportunity, I would like
to thank publicly Felix Linder for his comment in a security conference
during an one presentation of mine.




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


I mean that since atomic are processed in a different queue (and hence, for
OpenBSD is not considered an overalpping fragment), there should be an Echo
Reply back. If they weren't processed differently, the other two fragments
should also be dropped.



>
>
> * 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...
>
>
Yeh, exactly. It is not actually an overlapping fragment in this case.
Please have in mind that this is a very special case of a scenario where a
fragment deliberately overlaps with other(s). The used terminology is based
on the tested scenario. To be precise though, in this specific case and AS
LONG AS a different queue is implemented by the tested OS, the atomic
fragment is not an overlapping one. However, if the same queue is used,
then it is an overlapping one.



>
> * 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.
>
>
Yes, but still, why to bother to implement a different queue if there are
no security issues? In sake of performance I suppose. Just a rhetorical
question.



>
> * 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. ;-)
>
>

Once again, great job Fernado. I appreciate a lot both tools as well as the
effort and the knowledge both of you have put on these. However, as a
pen-tester and security engineer, I always liked the idea of making my own
scripts, at least for fun. This is my point here. And I strongly believe
that good pen-testers or security engineers excel for their proficiency in
a scripting language, no matter how good tools exist out there, which
should be used of course when and where required.

Thanks again a lot for your feedback. I really appreciate it.

Antonios