Re: [secdir] SecDir review of draft-ietf-netlmm-pmipv6-mib-05

["Glenn M. Keeni" <[e-mail]>]

Hi,
  Thanks for the review. The response follows.
> ** What about the completeness of the two lists provided in
> section 6?
> For instance the MIB defines the pmip6Capabilities object with
> attribute MAX-ACCESS read-only (see p. 13). However this object
> is not listed in the security considerations sections. Is it
> a mistake? If yes, then does anything miss (I didn't check)?
This is not a mistake. Since it is read only, its value cannot
be changed by an attacker. And, revealing the capabilities cannot
be as harmful as other objects e.g. pmip6Status. [ I will agree
that a miscreant may want to physically destroy all objects that
have LMA and or MAG capabilities in order to shutdown a PMIPv6
network. The pmip6Capabilities object may be misused in that manner. But
that is a generic argument, and holds for ALL the PMIPv6MIB
objects.] So, we have not listed this object as one which is
"particularly sensitive and/or private".
The generic risk aspects are covered in the last paragraph of the
security considerations section [copied from the boilerplate].
The 2 lists are complete to our knowledge.
Please let us know if there are any risks/vulnerabilities that
are worth mentioning.

The remaining comments relate to the boilerplate which we have
followed to the dot.

Cheers, Glenn

>
(2011/04/11 22:50), Vincent Roca wrote:
> Hello,
> 
> 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.
> 
> 
> Globally, the "Security Considerations" section is well
> written and provides details for the associated risks.
> It clearly RECOMMENDs the use of SNMPv3, which should not come
> as a surprise given the risks associated to previous versions.
> This "Security Considerations" section is globally similar
> to that of RFC4295 (MIPv6 MIB).
> 
> A few comments:
> 
> ** What about the completeness of the two lists provided in
> section 6?
> For instance the MIB defines the pmip6Capabilities object with
> attribute MAX-ACCESS read-only (see p. 13). However this object
> is not listed in the security considerations sections. Is it
> a mistake? If yes, then does anything miss (I didn't check)?
> 
> 
> ** Clarification needed:
> It is said:
>    "Even if the network itself is secure (for example by using IPsec),
>     even then, there is no control as to who on the secure network is
>     allowed to access and GET/SET (read/change/create/delete) the objects
>     in this MIB module."
> I'm rather surprised that no ACL (or similar) functionality
> be available. If IPsec is enabled, then hosts are authenticated
> (using one of several techniques) and it's no longer a big deal
> to check the authorizations associated to the peer. So that's
> surprising.
> 
> BTW, you can maybe remove the redundant "even then," in above
> sentence.
> 
> 
> ** Wrong reference:
> It is said:
>    "It is RECOMMENDED that implementers consider the security features as
>     provided by the SNMPv3 framework (see [RFC3410], section 8) [...]"
> Section  is not the section of interest as it only focuses
> on the standardization status. More interesting sections in RFC3410
> are:
> - section 6.3 "SNMPv3 security and administration", and in particular
> - section 7, in particular section 7.8 "user based security model".
> 
> NB: RFC3410 is from Dec 2002. At that time using MD5/DES was not an
> issue, now it is. The last sentence of RFC3410/section 7.8 mentions
> on-going work on using AES in the user-based security model. If this
> work gave birth to an RFC, that's probably a good document to refer
> too.
> 
> 
> ** Obscur:
> The last sentence of this section:
>    "It is then a customer/operator... them."
> could easily be improved (split the sentence, please). As such it
> remains rather obscure.
> 
> 
> I hope this is useful.
> Cheers,
> 
>     Vincent