[Last-Call] Secdir last call review of draft-ietf-pim-3810bis-10

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Reviewer: Valery Smyslov
Review result: Has Issues

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

THe document describes the Multicast Listener Discovery protocol version 2
(MLDv2) for IPv6. This protocol allows IPv6 routers to discover the presence of
multicast listeners on directly attached links, and to discover which multicast
addresses are of interest to these listeners. The draft is well written and
easy to understand. There are few issues though, that relate to security of the
protocol.

I think that the Security Consideration section should be expanded and be
rewritten in a more structural way. In particular, it should be mentioned that
the protocol lacks any cryptographic protection, thus its messages are not
authenticated, provide no confidentiality and can be replayed. Then I would
discuss the consequences of each of these deficiencies.

The lack of replay protection seems to have no effect on the protocol security,
because it is (at least it should be) designed so that it tolerates IP packets
duplication (correct me if I'm wrong, I read the protocol itself briefly, but
this was my impression).

The lack of authentication leads to possible message forgery. The corresponding
attacks are described in the draft, however, I'm not sure taht the list is
complete. For example, it seems to me that forged Current State Report message
from a malicious node may report a lot number of faked listening multicast
addresses, aiming to consume router's resources (a kind of DoS attack).

The lack of confidentiality is not discussed in the draft. In fact, it leads to
privacy issues - any passive attacker on the local link can learn what
multicast addresses other nodes are listen to, which may be quite sensitive
information.


-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux