Review of IPv6 Implications for Network Scanning

["Soininen Jonne (NSN FI/Espoo)" <jonne.soininen@nsn.com>]

Hello everybody,

Now (finally) I have reviewed the network scanning document. I thing in a
confused state in Prague, I decided to volunteer for it. (Perhaps, I was
just stretching my hand and Fred thought I was volunteering...)

Anyways, I have gone through the document and it seems mostly ready to go
forward. I have one more substantial comment and then a couple of
kind-of-my-personal-opinion-do-what-you-want-with-it-comments. However, in
general I think the document is in pretty good shape, and I leave the
decision whether to take these comments into account to the author. (The
significance is not too high)...



"Technical" comment:
====================

Section 5.5. Rolling Server Addresses:

I don't know if I now open an old can of worms and this was already
substantially discussed in the mailing list in the past. However, I find
this section a bit silly. The idea of a server is to be locatable. Actually
you make it easier reachable by adding its address to the DNS usually. So,
there are usually easier and more effective ways of finding it than scanning
the whole network. For instance, if you want to attack the mail server of a
network, you don't usually scan the whole network, but look at the
appropriate MX record - just the same you would do if you want to send mail
to that network. So, advising people to change the addresses on their
servers seem unlikely to bring any benefit.

I don't think the section is per se harmful. However, it might confuse some
readers. An I think the section not particularly useful either. I would
propose to remove it completely.


Editorial comment:
==================

1) Abstract: The abstract is a bit long to my taste, and might confuse the
reader. I would encourage the author to think about rewording it in a way
where you could see right away that this is a document to give guidance on
how to mitigate the risk of network scanning in IPv6 networks. The
information about the differences of the address space sizes in IPv4 and
IPv6 can be in the introduction, though. However, IMHO the purpose of the
document should be clearly, shortly, and directly readable from the
abstract.

2) Conclusion: The summary in the end of the conclusion section (comprising
more than half of the whole section) is IMHO redundant. This kind of short
summary is used often in academic papers, but I don't think they are needed
in an IETF RFC. 


Cheers,

Jonne. 


-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: jonne.soininen@nsn.com