Re: ISMS working group

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 mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf