[Gen-art] FW: [Fwd: Gen-art review of draft-ietf-enum-infrastructure-07.txt]
I'm forwarding this review which did not seem to make it to the archives. Original Message Subject:Gen-art review of draft-ietf-enum-infrastructure-07.txt Date: Thu, 19 Jun 2008 20:51:03 +0100 From: Elwyn Davies [EMAIL PROTECTED] To: General Area Review Team gen-art@ietf.org CC: Mary Barnes [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], IETF Discussion [EMAIL PROTECTED] I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. [Apologies for not making the Last Call deadline.] Document: draft-ietf-enum-infrastructure-07.txt Reviewer: Elwyn Davies Review Date: 19 June 2008 IETF LC End Date: 16 June 2008 IESG Telechat date: - Summary: This document is almost ready for the IESG. There are a couple of semi-editorial issues that it would be good to flesh out as noted below and the IANA considerations are incomplete. It may also require additional statements regarding the IAB's actions on the administration of the new sub-domain of .arpa in line with RFC 3761. Comments: 1. The structure of the Infrastructure ENUm domain: The term 'parallel namespace' is used in the Abstract and s3 implicitly importing the mapping of E.164 telephone numbers to URIs as set out in RFC 3761. I think that to make it quite clear what is going on, it would be worth stating something like: Parallel namespaces means that Infrastructure ENUM provides an (additional) Dynamic Delegation Discovery System (DDDS) database which follows the rules set out in Section 2.4 of RFC 3761, except that at stage 4 the string .[IANA TBD - maybe i164].arpa is added rather than .e164.arpa. [This might require a reference to RFC 3403]. 2. Infrastructure ENUM Tier 2 resource records (s3, para 2): This terminology is pure PSTN and needs explanation for the RFC audience. 3. A question: RFC 3761 makes comments that only diallable numbers should be presented to the database.. is that equally true for Infrastructure ENUM?I understand that blocks of numbers owned by a provider might be registered even if they aren't all in use. Does this require a comment? 4. RFC 3761 takes over the delegation of of e164.arpa, and gives instructions to IANA regarding this delegation. This document should make similar statements about the new subdomain (e.g. i164.arpa). 5. RFC 3761 contains statements about IAB actions relating to the e164.arpa domain. Presumably similar statements are needed for the new domain. These need to be agreed with the IAB (I know there has been discussion already). This may be no more that a further enlargement on the 'parallel namespace' clarifcation above. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] FW: gen-art review of draft-ietf-rserpool-policies-09.txt
Another one that didn't seem to make the mailing list/archives. -Original Message- From: Elwyn Davies [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2008 12:22 PM To: General Area Review Team Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Barnes, Mary (RICH2:AR00) Subject: [Gen-art] gen-art review of draft-ietf-rserpool-policies-09.txt I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-rserpool-policies-09.txt Reviewer: Elwyn Davies Review Date: 17 June 2008 IESG Telechat date: 19 June 2008 Summary: The editorial and immediate technical issues with -08 have been fixed. I remain unconvinced about the appropriateness of the structure of the policy elements as expressed in my last call review. However since this is now intended for experimental, the value and usefulness of the proposal will be tested in the fire of usage, so I think it can be passed as ready. I also had some reservations about the lack of explanation as to how the policy elements are used by the protocols. Communications with the authors suggested that the protocol documents explained this, but a quick scan of the protocol documents did not fully reassure me on this front. It appears that at least some of the explanation is not in the drafts but in the papers referenced in the drafts. Again this is not fatal for experimental status, but would need fixing up for standards. Comments: These are the general comments I made at LC together with the authors' responses: 1. Why do policies appear on the wire in this way? Do the individual servers care about the policy of the group? Would it conceivably work Yes, they do. They all use the same policy (with possibly different paraeters). if they weren't all conforming to some preconfigured policy? Is this expected to change over time? Would weights change over time? Seems to The parameters may change over time. me that policy is a preconfigured characteristic of the group. Maybe Preconfigured would be static. weight is something that a server might communicate during sign on. Load is dynamic and probably needs to be propagated from time to time. Yes. These are all conflated in these protocol elements. Is this good design? Who really needs to know about policies dynamically? Every node, which does the pool element selection: ENRP server and Pool user. So it must be communicated. 2. Why should pool users have to worry about pool policy? They just Because they can do the pool element selection. want a server. They don't want to have to (and IMO shouldn't have to) try to second guess the pool controllers by munging around it what was allegedly already a prioritized list, surely? In order to do this, Normally the pool elements do the selection. It is only an option for the ENRP servers to not give out the complete list. especially in the adaptive cases, the pool user needs the weight and load (according to the policy used) for each server passed in the list of servers in response to the request on the rserpool server. It isn't at all clear that this is what happens. ___ 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 reviewof draft-ietf-opsawg-snmp-engineid-discovery-02.txt
On Wed, Jun 25, 2008 at 09:52:42AM -0700, Randy Presuhn wrote: 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. 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. 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. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ 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 LC reviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt
On Wed, Jun 25, 2008 at 12:01:46PM -0700, Randy Presuhn wrote: 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. Well, as you said, this is not the same. ;-) 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). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ 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
On 2008-06-26 07:01, Randy Presuhn wrote: 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. I agree. That was the intention of my suggested change (but as Juergen noted, it can be read differently). Brian ___ 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
Re: [Gen-art] [OPSAWG] Gen-ARTLCreviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt
Hi, Just a touch of perspective. I joined the SNMP community because SNMPv2-party was so secure, network management applications would no longer be able to do autodiscovery of SNMP-capable devices. The autodiscovery we wanted to be able to do included being able to detect what type of device it was we were talking to, so we better understood how to monitor and manage it. An attacker might benefit from knowing the type of device as well, so they can better understand how to attack it. When doing autodiscovery, we typically used sysObjectID, not snmpEngineID. I think the system group is still recommended to be accessible via noAuthNoPriv, so I can already learn most of what an snmpEngineID might reveal via other accessible objects. From my point of view, and I think it was consensus, the snmpEngineID is meant to be accessible via noAuthNoPriv so even SNMPv1/2c implementatins that implement this MIB could be identified independent of the currently-assigned IP address. (I know the reality is that all the application developers who identified nodes by IP address did not change their applications to use engineIDs, but that was part of the original purpose). I think the benefit to operators is greater than the risk of giving the same benefit to attackers. I am not convinced this information is sensitive. How about Making this accessible via noAuthNoPriv will benefit legitimate tools that try to algorithmically determine some basic information about the device. This information may also benefit attackers trying to fine-tune their attacks. The information exposed can usually be gotten through traffic analysis. For interoperability, we RECOMMEND making this information accessible using noAuthNoPriv. dbh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Randy Presuhn Sent: Thursday, June 26, 2008 6:07 AM To: General Area Review Team; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [OPSAWG] Gen-ARTLCreviewofdraft-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 ___ OPSAWG mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/opsawg ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
