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

[Sri Gundavelli <[e-mail]>]

Hi Jari,

We will address these comments.

Thanks Vincent for the review.


Regards
Sri



On 4/12/11 5:09 AM, "Jari Arkko" <[e-mail]> wrote:

> 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
>> 
>>   
>