RE: -sO for IPv6

["Dario Ciccarone (dciccaro)" <dciccaro () cisco com>]

> On Wed, Jun 15, 2011 at 05:40:27PM -0500, Dario Ciccarone 
> (dciccaro) wrote:
> > Hm. This may end in a "TL;DR" . . . 
> >
> > I tried it against a couple devices - some observations:
> >
> > 1) For the actual extension headers (Hop-by-Hop (0), Routing (43),
> > Fragment (44), Destination Options (60), No Next Header 
> (59)) - we're
> > just setting the NH field on the IPv6 header to each value. 
> There's no
> > attempt to actually build a valid extension header (well, 
> it IS valid
> > for 59 ;)). I think it would be more accurate if the 
> extension header
> > was properly formed. I can provide pcaps for each one of them, if so
> > needed.
>
> This is the same situation as for IPv4. We only send proper 
> payloads for
> a small number of protocols (ICMPv6, TCP, UDP, SCTP) and for 
> the rest we
> send empty payloads. Please send your packet captures so we 
> can make it
> better.

Attached. And indeed, as I know nmap does so (send proper payloads) for
some protocols, doing the same for extension headers only seems logical
to me. God forbid there was to be a queso6 doing that while nmap does
not :^)

<SNIP>

> > 4) There will never be anything back for an IPv6 packet 
> with NH = 59 -
> > unless being filtered, and filtering device sending back 
> ICMPv6(1,1).
> > Should, IMHO, be assumed open - if you're doing IPv6, you *have* to
> > support them all (0, 43, 44, 59 and 60) - so.
>
> I think then that open|filtered/no-response is appropriate.

Well, at the end of the day, it doesn't really matter, right? It's
either because it's "open, but not getting anything back, as expected"
or "being filtered by a device not sending us back ICMPv6(1,1)" - in any
case, not like someone is going to be exploiting any vulnerability on
proto 59 ;)

About the attachment - all packets follow the same format: IPv6
header/extension header/ICMPv6 Echo Request. I only did Hop-by-Hop,
Routing Header Type 0, Fragment Header and Destination Options. Routing
Header Type 0 bounces only once, even if it has two nodes on the list -
because my Linux machine doesn't do RH0. And the options are both Pad1
and PadN - could have been only 6*Pad1, but having both gives you
flexibility :)

Attachment: nmap_sample_ext_hdr.pcap
Description: nmap_sample_ext_hdr.pcap

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/