Re: Gsoc 2011 idea about IPv6

[Xu Weilin <mzweilin () gmail com>]

David,
Thank you for your guidance. I have learnt notes.txt from SVN and read the
given papers carefully. I would like to express my ideas here before writing
the formal proposal.
1. OS Dectection on IPv6
Nerakis's thesis has shown the existing IPv4 tests methods, such as port
scanning, TCP and UDP figerprinting, can be reused effectively in IPv6
environment. Besides, Nerakis's thesis also mentioned the IPv6 extension
header based methods though they are not as effective as TCP/UDP based. Note
that this work on IPv6 extension header done 5 years ago was not so
complete, so we may get different results in new tests.
Beck's team has done much work on NDP based OS fingerprinting.By sending a
series of NS packet, we get different replies from different OSes.
SinFP can match IPv6 responses against IPv4 fingerprints, using three
mapping rule on IP header.
In conclusion,
For one-hop IPv6 fingerprints, all methods mentioned above are possible.
For over-Internet IPv6 fingerprints, NDP based method and IPv6 Hop-by-Hop
option header based method are disabled.
New IPv6 tests can be based on IPv6 extension headers.
In addition, I suppose a pure database of OS fingerprints and an accurate
matching algorithm are crucial.
 2. Hosts Discovery on IPv6
Do hosts discovery in the same subnet is easier in IPv6. The alive6 tool and
its method is quite effective.
* The alive6 tool sends
  *1. ICMPv6 echo request to ff02::1.
  *2. Invalid extension header (0x80) followed by ICMP echo request to
ff02::1.
  *3. Hop-by-hop header followed by ICMP echo request to ff02::1.
In addition, we have another method based on SLAAC to achieve hosts
discovery. Considering some hosts may refuse ICMPv6 echo Ping and the other
known probe methods, the SLAAC based method is essential since hosts
couldn't refuse RA packet unless SEcure Neighbor Discovery(SEND) protocol is
used.
*The procedure of StateLess Address Autoconfiguration(SLAAC) is
 *1. Router Advertisement with an IPv6 Prefix infomation to ff02::1;
 *2. Hosts receiveing this RA packet configure its IPv6 address with the
Prefix automatically;
 *3. Hosts send NS packets to make sure that no other hosts use this
address.
In order not to disturb the network, the RA packet should be carefully
constructed within three principles:
1) Not a default router;
2) Address prefix should be insignificant in the network. A random
Unique-local Address prefix is suitable.
Short valid life time.
(If SLAAC based method is allowed to be used for hosts discovery, it also
can be used for OS detection though it will not be so complete and
effective. A known parameter Prefix Length will help to detect OSes. The
length of prefix to do SLAAC should be 64bits long in most cases by RFC4862
Section 5.5.3 point d. Some OSes will ignore the nonstandard prefix
advertisements but others still use it in my tests. The MLD v1/v2 protocol
will help to do OS detection too.)
For hosts discovery over Internet, it becomes harder on IPv6 for its address
space is quite large. We can take use of these methods below by NSE scripts
before we find a more effective method.
1. Avoid scanning address block that can't be routed.
The global BGP information is available on http://www.routeviews.org/.
Take use of SLAAC mechanism.
Since most IPv6 networks use SLAAC mechanism to configuring IPv6 address and
most OSes generate EUI-64 by use of MAC,the scanning space is reduced to /24
if the prefix and ether vendor have been confirmed.
The vendor codes are available on these pages:
http://standards.ieee.org/develop/regauth/oui/oui.txt
https://db.uga.edu/network/public/vendorcode.cgi
3. Take use of IPv4-mapped or -compatible address
Actually I don't think it is necessary since we can reach the goal through
IPv4. We had better focus on native IPv6 network.
 I plan to implement IPv6 host discovery first. The work will involve the
raw packet host discovery, traceroute6 and NSE scripts. I'm also interested
in OS detection but I'm not sure whether I have enough time. Please give me
an advice:)


On Fri, Mar 25, 2011 at 12:06 AM, David Fifield <david () bamsoftware com>wrote:

> On Thu, Mar 24, 2011 at 10:21:55PM +0800, Xu Weilin wrote:
> > Hi all,
> > I have run ipv6.c program on my UBUNTU 10.10 and found some interesting
> > things.
> >
> > 1) The Traffic Class and Flow Label of IPv6 header cannot be set
> correctly
> > with the macro function ip6_pack_hdr() of Libdnet.
> >
> > In the main() function we write
> >
> > ip6_pack_hdr1(ip6_hdr, 0x12, 0xabcde, sizeof(packet) - sizeof(*ip6_hdr),
> > IP_PROTO_HOPOPTS, 13, src[0], dst[0]);
> >
> > The Traffic Class should be 0x12 and the Flow Label should be 0xabcde,
> but
> > the values I captured in Wireshark were 0x10 and 0x0. The reason is that
> > Libdnet defines a specific operation on ip6->ip6_flow with a flowlabel
> mask:
> > ip6->ip6_flow = htonl(((uint32_t)(fc) << 28) & \
> >     (IP6_FLOWLABEL_MASK | (fl)));
> >
> > If I replace it with this:
> > ip6->ip6_flow = htonl(((uint32_t)(fc) << 20) | \
> >     ( (fl)));
> > Then the related values will be correct.
> >
> > Since the flow label may be used for OS detection, we should be careful
> > about it.
>
> Oh! Good find. I forgot to mention that I found the same bug, and it is
> fixed in newer versions of libdnet (including the libdnet that comes
> with Nmap).
>
> > 2) send_ipv6_ip() couldn't work on my UBUNTU 10.10.
> >
> > The sentence below returns '-1'
> > sd = socket(AF_INET6, SOCK_RAW, hdr->ip6_nxt);
> >
> > and the next sentence 'perror("socket");'
> > prints 'socket: Protocol not supported'
> >
> > This may need more tests.
> >
> > I prefer to send_ipv6_eth() and send_ipv6_ipproto_raw() since they work
> well
> > and they are more powerful.
>
> The different functions work on different operating systems--I think all
> three are necessary. Linux treats IPPROTO_RAW differently and
> incompatibly from different operating systems--it acts like IP_HDRINCL
> for IPv4 (header is included with packet payload). Linux uses
> send_ipv6_ipproto_raw. Other operating systems (like BSD) treat
> IPPROTO_RAW as nothing special, just IP protocol 255. They use
> send_ipv6_ip and use special functions to set header values. Windows
> doesn't support raw sockets at all, and the only way I know of is to use
> raw Ethernet sending with send_ipv6_eth. Other operating systems can
> also use send_ipv6_eth, but only on Ethernet devices, and not, for
> example, PPP devices. Raw sending on Windows with a non-Ethernet doesn't
> work at all, but it's the same for IPv4. So I think all three functions
> are necessary.
>
> David Fifield



-- 
Regards
Xu Weilin
Beijing University of Posts & Telecommunications
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/