Margaret, I find myself repeating statements I've made recently, and so I'd propose that you catch up on my other messages. But for the record... > > Hi Eliot, > > I have, of course, read the draft that you cited below, but the term > "call home" is not defined or used in that draft... Because it wasn't necessary to do so, as you allude below. The draft you haven't yet read is SNMP/SSH. The working group decision was made absent a draft. Doesn't that bother you at all? > > The document does discuss the concept that either end of the SNMP > exchange could initiate the BEEP connection at the transport level, but > I don't see that it explains anywhere how/when/why a command responder > would _decide_ (or even know how) to contact a command requestor and/or > how a command responder could find a command requestor if it were not at > a fixed, globally addressable location. As I wrote previously this is a matter for configuration and policy. There are some obvious configurations (some are obviously good and others are obviously bad ;-) and some non-obvious ones. It is also a matter for a working group to discuss. The conversation within the WG has thus far been cut short by AD decree. > > IMO, there is a lot more to building a system that is capable of SNMP > initiation in both directions than simply having a mechanism to set-up > the transport connection from the command responder to the command > generator. Of course there is. Nobody said otherwise. There are matters of end point authentication, for instance. But these problems are not insurmountable. Perhaps you would like to participate in those discussions, assuming we can find a place where they are not ruled out of scope? > It would also be possible to set-up an SSH connection from > either end, but I don't see how that even begins to offer the benefits > that you've attributed to "call home". You asked me for a concrete proposal. I responded with one using BEEP as an example. BEEP / SSH are bits on a wire. Either can be used, but as I've written previously the horse I have in the game is whether CH is supported and whether trap-based polling will properly function through firewalls (something very much in doubt at this point), and not whether we're talking about BEEP or SSH. > > None of this seems very material to the ISMS discussion, though... As I've written, The reason it is relevant at all is that the ISMS working group has decided to make use of a transport where firewall traversal becomes a real possibility, and I (and others) have needs for it. > > Today SNMP (whether it is running over UDP or TCP) doesn't have the call > home feature. Do you really think it is reasonable to tie the addition > of that feature to the definition of a new security mechanism for the > existing SNMP protocol? If so, why? Margaret, if I only thought it was reasonable to tie these two functions together we wouldn't be having this discussion amongst a the IETF and IESG. I think it is UNREASONABLE and a huge waste of resources to consider an SSH/TCP solution without taking into account connection direction. Here's why: - in its current direction the protocol will fail to be useful in the face of firewalls. In this day and age that is a foolhardy approach. [It would be excusable failure if SNMP were to remain UDP-based since firewall/NAT traversal is already problematic.] Under the current approach the basic concept of trap-based polling will fail in the face of firewalls. - why now? because as I wrote earlier we really don't want to churn SNMP continuously. Put yourself in the position of a tools developer. What sort of investment am I going to put into development, q/a, release engineering, documentation now when I know this is hanging over my head? In short, if we're going to turn the crank at all on SNMP, let's make sure the resultant will work and will be useful for a while without having to go do it again six months or a year down the road. > > IMO, we need to try to do our work in manageable chunks in the right > groups/areas. A security area working group working on a new security > mechanism for the existing SNMP model is one chunk. Perhaps an OPS area > WG working on an optional SNMP call home mechanism is another...? Yes, you've repeatedly said this. And I've repeatedly responded with two reasons why this work should continue in a single working group: 1. The ISMS working group has had the correct set of people with eyes on the problem, including security experts who ought to see their concerns (such as those raised by Steve Bellovin and others) addressed as well as network management people. 2. And as has been pointed out repeatedly (first by Steve Bellovin and then by others), there are security implications here. We currently need and have the correct the mix of security and management people in the working group to both develop and properly vet the work being done. > I > don't see how the level of change/disruption to the vendor community is > substantially affected by whether these two separate mechanisms are > defined in one IETF working group or two. Because you view the mechanisms as separate. As currently envisioned the approach proposed will fail in the general case in the face of firewalls and NATs(*). Eliot -- ps: I agree with Melinda that there are differences between the two, but for common cases the results are the same. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf