Allison <inline> Tom Petch ----- Original Message ----- From: "Allison Mankin" <mankin@xxxxxxx> To: <ietf@xxxxxxxx>; <isms@xxxxxxxx> Cc: "TSV Dir" <tsv-dir@xxxxxxxx> Sent: Thursday, April 16, 2009 8:57 AM Subject: Transport directorate review of Last Call: draft-ietf-isms-tmsm > Transport directorate review of Last Call: draft-ietf-isms-tmsm > Transport Subsystem for the Simple Network Management Protocol (SNMP) > > I've reviewed this document as part of the transport area > directorate's ongoing effort to review key IETF documents. These > comments were written primarily for the transport area directors, but > are copied to the document's authors for their information and to > allow them to address any issues raised. The authors should consider > this review together with any other last-call comments they > receive. Please always CC tsv-dir@xxxxxxxx if you reply to or forward > this review. > > Overall, this document gets a thumbs-up from me. And for extra measure > I read over draft-ietf-isms-transport-security-model-12.txt to > understqnd its context and found the two very well meshed. I found > both of them a very strong base to the in-progress document > draft-ietf-isms-secshell-15.txt. > > A top-level comment/question has to do with the draft's use of the > TDomain/TAddress textual convention from RFC 2579, instead of RFC 3419. > The revision notes call this out as mid-course choice and I'm sure the > working group and the MIB experts have good reasons for it. But > is a transport running on, say, TCP-IPv6 going to be appropriate > with RFC 2579? In any event, it would be good since this is a > transport-focused document if you could add a NOTE about the > design choice of TDomain/TAddress. > > Here's what I'm reading in RFC 3419: > Transport endpoints which carry SNMP traffic SHOULD continue to use > the definitions from the SNMPv2-TM MIB module where applicable. They > SHOULD use the transport domain values defined in this memo for SNMP > transports not defined in the SNMPv2-TM MIB module, such as SNMP over > UDP over IPv6. Programs that interpret transport domain values > should in addition accept all the transport domain values defined in > this memo in order to provide interoperability in cases where it is > not possible or desirable to distinguish the protocols running over a > transport endpoint. > > > Section 2 > > Though I'm reviewing for the tsv-dir, I can't resist both > complimenting and fussing a bit about the paragraph in Section 2 about > the individual who considers three approaches to security and ends up > hiring a company that can handle all his or her needs comprehensively: > > The individual therefore > achieves the desired security, with no significant effort on his part > other than identifying requirements and verifying the quality of > service being provided. > > The discussion is very clear. But "with no significant effort...other > than identifying requirements" is like the "small matter of programming." > > Section 3.2.1 > > At the mention of multiple transport mappings for SNMP, please give > a reference. > > Section 3.2.1.3 > > A secure Transport Model will establish an authenticated and possibly > encrypted tunnel between the Transport Models of two SNMP engines. > After a transport layer tunnel is established, then SNMP messages can > be sent through the tunnel from one SNMP engine to the other. > Transport Models MAY support sending multiple SNMP messages through > the same tunnel. > > Is the MAY sentence at the end of paragraph necessary? From the > standpoint of a transport person, it's hard to envision that an > implementor would establish security and tear it down per message, > but this MAY is saying that's the default. Later you advise > implementations against this. Taking the next two comments together, > 3.3.1. No SNMP Sessions > > The transportDomain and transportAddress identify the transport > connection to a remote network node. Elements of the transport > address (such as the port number) might be used by an application to > send a particular PDU type to a particular transport address. > > This paragraph describes a heuristic to get around the fact that > "the transport subsystem does not have access to the pduType." > What do pduTypes include? What's a useful example of this hint > that makes this reversal worth including? > > Readability of the two paragraphs before: > The Transport Subsystem may support transport sessions. However, the > transport subsystem does not have access to the pduType, so cannot > select a given transport session for particular types of traffic. > > Certain parameters of these ASIs might be used to guide the selection > of an appropriate transport session to use for a given request by an > application. > To what does "these ASIs" refer? This hint isn't very clear either. > Transport readers want to know... On the one hand, An SNMP Architecture has no concept of sessions (or connections) nor do these documents introduce it. On the other, there are two very different applications, Command Generator/Command Responder, where the 'manager' initiates the secure 'connection', and Notification Originator, where the 'agent' initiates the secure 'connection'. And this in turn has a significant impact on where security credentials need to be provisioned, which in turn is the issue that led to the existence of isms. Early on, I saw consensus in the WG that an SSH connection could be set up in advance, eg by a 'control plane' and that the application, CG or NO, could then hook into it by a suitable selection of parameters available to it (RFC3411 4.1.1) at the ASI (application interface). It is this that has been steadily eroded and what you see are its dying embers. The philosophy now is that the application, the user, has (almost) no say in this, it is up to the SNMP engine to decide when and how to set up what secure connections and what traffic will then go over them and that typically, the first message from a CG or NO will create the secure connection to a transport -Domain/-Address and that after that, all application traffic to that address will use that connection (given that with ssh, it will have the greatest possible securityLevel). As you may gather, I am in the minority that thought the original approach was a good idea but did think that this issue might arise at IETF Last Call, which would provide a sanity check that the consensus of the IETF was the same as that of isms. So yes, the text in -tmsm is coy, perhaps hoping that noone will understand what it means:-). Look back at earlier drafts, from 2006, and it is all much clearer:-( Tom Petch > > 3.3.4 > > If a secure transport session is closed between the time a request > message is received, and the corresponding response message is sent, > then the response message SHOULD be discarded, even if a new session > has been established. The SNMPv3 WG decided that this should be a > SHOULD architecturally, and it is a security-model-specific decision > whether to REQUIRE this. > > In other words, under USM, the late response MAY be accepted. > This text says that under TSM the security model could decide to > accept late responses. The cases are very different from each > other and I think there should be a warning that this MAY > could be complex to get right. > > > TYPO: > Commander Generator -> Command Generator > > > 7.1 Coexistence, Security Parameters, and Access Control > > This section points out that enabling security models prior > to transport-based security will have the result of bypassing > the secure transport. Therefore, it recommends against > trying coexistence and recommends that the secure transport > model detect that the tmStateReference cache is not populated > due to use of these other models and fail. However, the > section also states that the previous User-Based Security > Model differs from the transport-based security model in > that it was designed not to depend on external network > services. The draft talks about "provisioning" USM AuthPriv > for use when TSM is too stressed to work: > > It is RECOMMENDED that operators > provision authPriv USM to supplement any security model or transport > model that has external dependencies, so that secure SNMP > communications can continue when the external network service is not > available. > > Please make this clearer. This isn't a coexistent USM, right? > It's a failback that is enabled when access to dependencies is > not possible or when there's other stress determined. > > 6. IANA Considerations > > For completeness and for some Security Models as yet > unknown, you might want to add a registration for > TCP to the SNMP Transport Domain: > > tcp snmpTCPDomain > > The reference would be this RFC once published. > > > > > > > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf