Re: [Gen-art] Gen-ART review of draft-ietf-bfd-mib-17
Hi - From: Sam K. Aldrin aldrin.i...@gmail.com Sent: Apr 17, 2014 6:24 PM ... Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17 ... My only concern is with the new extension MIB's. If the base MIB (this MIB) has write access, future extension MIB's may be forced to support write-access. And how, exactly, does the fact that a base MIB module permits write access force extension MIB modules to require (or even permit) write access? It's perfectly reasonable SMI to define an AUGMENTS table consisting entirely of read-only objects. Randy ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-bfd-mib-17
Hi - From: Sam K. Aldrin aldrin.i...@gmail.com ... Sent: Thursday, April 17, 2014 9:53 PM Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17 ... In order to support new functionality, we are extending/augmenting existing base MIB and in addition some write-access objects as well. If we make those new ones read-only objects, then only some objects or tables could be used with write-access and these new objects (read-only) have to be configured differently. In other words, full functionality cannot be provided. This got nothing to do with SMI. Then what's the problem? If the WG has consensus to add functionality, and that functionality logically requires a read-write MIB module of extension, the IESG policy already allows for such cases. Randy ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [OPSAWG]Gen-ARTLCreviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt
Hi - From: Juergen Schoenwaelder [EMAIL PROTECTED] To: David Harrington [EMAIL PROTECTED] Cc: 'Randy Presuhn' [EMAIL PROTECTED]; 'General Area Review Team' gen-art@ietf.org; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, June 26, 2008 12:59 AM Subject: Re: [OPSAWG]Gen-ARTLCreviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt ... An an editor, I need to understand the WG consensus. I currently see three options on the table: a) document the potential information leakage associated with snmpEngineID discovery perhaps with a note that this information can get out in other ways b) declare that this potential information leakage is a feature that is RECOMMENDED to support I'd quibble with the to support - we're not talking about an implementation decision, but rather a deployment / usage decision, since the VACM configuration is what would determine how much leaks, beyond what the protocol itself exposes. c) remove all discussion about this issue and simply stay silent, following the spirit of the USM standard ... So I agree in spirit with a+b Randy ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [OPSAWG] Gen-ART LC reviewof draft-ietf-opsawg-snmp-engineid-discovery-02.txt
Hi - From: Juergen Schoenwaelder [EMAIL PROTECTED] To: Brian E Carpenter [EMAIL PROTECTED] Cc: General Area Review Team gen-art@ietf.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, June 25, 2008 12:23 AM Subject: Re: [OPSAWG] Gen-ART LC reviewof draft-ietf-opsawg-snmp-engineid-discovery-02.txt ... 5. Security Considerations ... If a device configuration permits non-secure SNMPv1/v2c access to a target system, then reading the snmpEngineID variable of the SNMP- FRAMEWORK-MIB will also reveal a suitable contextEngineID value for subsequent SNMPv3 usage. However, implementations should not rely on non-secure SNMPv1/v2c access and therefore MUST implement this specification to enable secure contextEngineID discovery. This is a little odd, since, as the previous paragraph indicates, the localEngineID mechanism is not intrinsically secure. I think the second sentence should be extended to: However, implementations should not rely on non-secure SNMPv1/v2c access and therefore MUST implement this specification to enable secure contextEngineID discovery whenever an SNMPv3 security mechanism is in use. The paragraph in question establishes an implementation requirement. Your proposed addition whenever an SNMPv3 security mechanisms is in use hints to a deployment decision, which for me does not go along with an implementation requirement. I have another problem with both versions of the text in question: both versions seem to imply that one must not use the USM method for discovery, referenced in the last paragraph of section 2 of the draft, and in contradiction to the first paragraph of section 3.2. I think the statements about when this technique MUST be implemented and SHOULD be used need to be more carefully scoped. BTW, I admit to being a bit baffled by the second paragraph of the security considerations section - why are we worried about attackers learning snmpEngineID values? Just exactly what attack would having this information facilitate? Randy ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [OPSAWG] Gen-ART LC reviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt
Hi - From: Juergen Schoenwaelder [EMAIL PROTECTED] ... Sent: Wednesday, June 25, 2008 11:13 AM Subject: Re: [OPSAWG] Gen-ART LC reviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt ... Any suggestion how to fix this? Would if be sufficient to add if a security model does not provide a suitable discovery mechanism for contextEngineIDs, that is: If a device configuration permits non-secure SNMPv1/v2c access to a target system, then reading the snmpEngineID variable of the SNMP- FRAMEWORK-MIB will also reveal a suitable contextEngineID value for subsequent SNMPv3 usage. However, implementations should not rely on non-secure SNMPv1/v2c access and therefore MUST implement this specification to enable secure contextEngineID discovery if a security model does not provide a suitable discovery mechanism for contextEngineIDs. This looks fine to me. BTW, I admit to being a bit baffled by the second paragraph of the security considerations section - why are we worried about attackers learning snmpEngineID values? Just exactly what attack would having this information facilitate? Depending on how the snmpEngineID is constructed, it may contain the enterprise ID identifying the device manufacturer or it may contain a MAC address which is otherwise not accessibe (and which also gives a hint about the manufacturer), or it might contain an administratively assigned text that might be useful to further target an attack. Is this something to be seriously worried about? I can't judge. Do we have such text in USM RFC 3414? Obviously not. Is the fact that USM is silent about this sufficient to not be worried? Again, I can't judge. Though obviously not the same, I'd lump this in with RFC 3414's commentary on traffic analysis attacks. The recommended VACM configuration in appendix A of RFC 3415 gives noAuthNoPriv read access to this information anyway. Randy ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [OPSAWG] Gen-ART LCreviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt
Hi - From: Juergen Schoenwaelder [EMAIL PROTECTED] To: Randy Presuhn [EMAIL PROTECTED] Cc: General Area Review Team gen-art@ietf.org; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, June 25, 2008 1:02 PM Subject: Re: [OPSAWG] Gen-ART LCreviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt ... The recommended VACM configuration in appendix A of RFC 3415 gives noAuthNoPriv read access to this information anyway. Not necessarily if you choose an initial-no-access-configuration (or I am misreading the A.1 item 5). True, though the initial-no-access-configuration is in some ways a pathological case. It begs the question of how the system *ever* comes to be managed. :-) I'm still not persuaded that SnmpEngineIDs should be regarded as sensitive information in general. With USM, they show up on the wire in the clear, perhaps revealing the most in the case of notifications. (msgAuthoritativeEngineID in the UsmSecurityParameters carried as msgSecurityParameters of SNMPv3Message) Randy ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
