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

[Jari Arkko <[e-mail]>]

Thanks for your review, Vincent. Authors, any comments?

Jari

Vincent Roca kirjoitti:
> 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
>
>