Subject: Network Scanning

From: "Prasanna Ram Venkatachalam" <[email-masked]>
Date: Sat, 5 Apr 2008 01:05:06 +0530

Hi all,

With the evolving IPv6 which will be a mandate soon(as far as i know), the
network discovery is going to be very difficult. Is there any optimized way
proposed so far which can be used with IPv6 for network discovery??
Please explain if there is any!

-- Thanks & Regards
Prasanna Ram
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 04 Apr 2008 23:51:12 +0200

Prasanna Ram Venkatachalam wrote:
> Hi all,
> 
> With the evolving IPv6 which will be a mandate soon(as far as i know), 
> the network discovery is going to be very difficult. Is there any 
> optimized way proposed so far which can be used with IPv6 for network 
> discovery??

ping6 ff02::1

Which should make every single host on a link answer to it.

For the rest, read the excellent paper by Steven M. Bellovin:

http://www.cs.columbia.edu/~smb/papers/v6worms.pdf

Greets,
  Jeroen

---

From: "Brian McGehee" <[email-masked]>
Date: Fri, 4 Apr 2008 15:01:16 -0700

"ping6 ff02::1

Which should make every single host on a link answer to it."

Answer with it's link-local address, which is probably not the goal.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jeroen Massar
Sent: Friday, April 04, 2008 2:51 PM
To: Prasanna Ram Venkatachalam
Cc: [email-masked]
Subject: Re: Network Scanning

ping6 ff02::1

Greets,
  Jeroen

---

From: "TJ" <[email-masked]>
Date: Fri, 4 Apr 2008 18:54:42 -0400

> Brian McGehee
> Sent: Friday, April 04, 2008 6:01 PM
> To: 'Jeroen Massar'; 'Prasanna Ram Venkatachalam'
> Cc: [email-masked]
> Subject: RE: Network Scanning
> 
> "ping6 ff02::1
> 

Unless autoconfiguration (SLAAC or Stateless DHCPv6) is in use and you can
derive the Global from the Link Local ... same EUI64.
Without more information, if you are on-link that ping is probably the
first/best approach.  
 	... although some OSes break the RFC and don't reply ... 

> http://www.cs.columbia.edu/~smb/papers/v6worms.pdf

/TJ

---

From: David Malone <[email-masked]>
Date: Sat, 5 Apr 2008 20:55:11 +0100

> Answer with it's link-local address, which is probably not the goal.

In that case use a Node Information Query for either the hostname
or list of addresses. KAME stacks support requests for the hostname,
which often proves useful. I don't use requests for address very often.

	David.

---

From: Sean Siler <[email-masked]>
Date: Mon, 7 Apr 2008 14:03:34 -0700

Microsoft based Operating Systems join the All Nodes On Link Multicast Group as specified by RFC 4291, but that RFC does not mandate that nodes must reply to ICMP echo requests.  So while we do not reply to pings to ff02::1, we are also in compliance with the RFC.

Sean Siler
IPv6 Program Manager
Microsoft
blogs.technet.com/ipv6

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of TJ
Sent: Friday, April 04, 2008 3:55 PM
To: [email-masked]
Subject: RE: Network Scanning

/TJ

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 07 Apr 2008 23:39:59 +0200

Sean Siler wrote:
> Microsoft based Operating Systems join the All Nodes On Link Multicast Group
 > as specified by RFC 4291, but that RFC does not mandate that nodes must
 > reply to ICMP echo requests.  So while we do not reply to pings to 
ff02::1,
 > we are also in compliance with the RFC.

Thus, as such, to identify this OS, one would just have to send an MLD 
Query on the link, receive the responses, and tada, you have, per the 
RFC, all the hosts that at least comply to the RFC, then substract the 
ones you receive an ICMP echo from et voila you know what is doing this 
trick, which currently means that it is most likely Windows-based as all 
the KAME's including even OpenBSD reply to the ANOL-ping. The KAME ones 
you can even do Node Queries to to get more data out of them.

As both MLD and ICMP Echo are ICMP packets, and both is 1 packet 
outbound (request/query), and several inbound (the replies), nothing 
really is of a difference.

Unless of course the OS is programmed to have a notion of a 'secure 
router' which would mean one need to do some spoofing, unless the switch 
is smart enough to detect&block those kind of action.

The real solution to on-link attacks is of course to compartmentalize 
the network and to have secure hosts in the first place. Then the only 
issue left is that rather annoying factor called humans :)

Greets,
  Jeroen

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 7 Apr 2008 18:12:13 -0400

> From: Jeroen Massar [mailto:[email-masked]] 

> Sean Siler wrote:
> > Microsoft based Operating Systems join the All Nodes On 
> > Link Multicast Group as specified by RFC 4291, but that
> > RFC does not mandate that nodes must reply to ICMP echo
> > requests.  So while we do not reply to pings to ff02::1,

And RFC 4443 (ICMPv6) also does not mandate a response to a multicast
query.

> trick, which currently means that it is most likely 
> Windows-based

To which on link multicast address would the MLD query be transmitted,
for this idea to work? RFC 2710 does not mandate a reply to these
multicast addresses:

"When a node receives a General Query, it sets a delay timer for each
multicast address to which it is listening on the interface from which
it received the Query, EXCLUDING the link-scope all-nodes address and
any multicast addresses of scope 0 (reserved) or 1 (node-local)."

Hmmm. No way to do a network discovery?

Bert