Subject: Re: [Isms] WG Review: Recharter of Integrated Security Model for

From: Keith McCloghrie <[email-masked]>
Date: Mon, 12 Sep 2005 12:21:22 -0700 (PDT)

Since the below requires of Eliot that he "make significant progress on
all of these issues", it is probably impossible to achieve in several
months, let alone a few days.  Thus, based on the below, the "final
determination" is a foregone conclusion.

Keith.
 
>     Eliot> I request an extension of the deadline for comments to
>     Eliot> September 21st on the following basis:
> 
>     Eliot>  - the period of comment has been less than a week, far
>     Eliot> shorter than the normal period of IETF-wide review.  - of
>     Eliot> the time allotted, the principle instigator of this review
>     Eliot> has been absent from debate for five days due to prior
>     Eliot> commitments.  That was me.
> 
> Hi, Eliot.  I have not made any determination as yet about whether I
> will pull ISMS from the Thursday telechat and am unlikely to make a
> final determination until the time of that telechat.
> 
> 
> When I originally ruled call home out of scope I gave you some
> suggestions for how to approach things from a process standpoint.  In
> evaluating your request I will consider how much progress has been
> made on these issues so far and on whether it is likely that you could
> make additional progress on these issues by September 21.
> 
> Let us go back and consider my original advice to you:
> 
>   When the charter is sent to me for IESG review, ask me to send it out
>   for external review (IETF wide) rather than just approving it; I will
>   honor such a request.  You will need a proposal ready to present to
>   the community when the charter comes out for review.  The proposal
>   should include proposed modifications to the charter to make call home
>   in scope.  In addition you probably want to answer the following
>   concerns:
> 
>   * People believe that architectural changes to SNMP should happen in
>     the management not security area.  Either convince them that this is
>     OK in the security area, propose moving the working group, or
>     propose splitting the work appropriately.
> 
>   * Address the concerns about the lack of MIBs and other facilities for
>     managing call home.  Have a proposal ready for what is involved in
>     doing the work.
> 
> 
>   * Understand concerns Bert is likely to raise and respond to them.
> 
> 
> 
> so, here are some specific questions related to our progress to date
> on these items.  Answering these questions will help me determine
> whether extending the review period to September 21 is likely to be
> productive.
> 
> 1) Have you proposed a specific set of charter changes?  Who has
>    supported these charter changes?
> 
> 2) How have you addressed the specific concerns about the location of
>    the work ?  Who has agreed with your proposed resolution?
> 
> 3) Is there a consensus emerging that CH needs to be solved as part of
>     ISMS?  This is the part where additional time is most likely to
>     help you, but I think it fair to ask who has supported blocking
>     ISMS on CH so far.  Note that people who support CH but who
>     believe it could be done in a separate working group or who have
>     not expressed an opinion do not count.  They may well count for
>     justifying support for a CH BOF or for justification of a
>     publication request for an individual submission adding CH to the
>     SNMP architecture.
> 
> 
> 4) What response have you given to concerns about whether the
>    architectural extensions for CH are sufficiently well defined?  Who
>    has supported this proposal?
> 
> 
> 
> 5) How are your discussions going with Bert to resolve his concerns?
>     What about other key members of the management community who have
>     expressed concerns?
> 
> 
> 
> Here's how I'm going to make a decision.  I believe that in order to
> get a change to the SNMP charter it is necessary to make significant
> progress on all of these issues.  I'm going to evaluate your answers
> and consider whether I think the progress to date makes it likely that
> you will have sufficient support for a new charter by September 21
> without significant opposition.  In other words whether the community
> and IESG can agree to the new charter by the end of the review period.
> If the progress to date makes it likely that we're headed in that
> direction, I'll grant the request.  Otherwise I will ask the IESG to
> approve the charter on Thursday.
> 
> 
> There's an internal issue that may well prevent the charter from being
> announced before the 21st even if no formal extension is granted.
> 
> 
> --Sam
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/isms
> 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Eliot Lear <[email-masked]>
Date: Mon, 12 Sep 2005 21:53:06 +0200

Sam,

I believe the approach you have proposed is quite simply wrong.  As an
AD you're supposed to provide technical oversight and not simply hold a
popularity contest.  If you have technical questions or wish to
challenge me on a technical point, I think that's fair game.

As I've written, the path we are headed down technically will not work
in the face of firewalls and NATs, and nobody has refuted this.

Furthermore you've heard from a reasonably large customer (Boeing) as
well as your predecessor on the prevalence of such middle boxes that
demonstrates the complexity of today's environment and the need for this
sort of functionality as part of the solution.

You've heard from an author of SNMP that the major architectural change
is the use of session based security and NOT CH, the same from the
former O&M AD and IETF chair.  You've heard from a service provider as
well as numerous members of the community who see the problem.

You may or may not have yet heard from other standards bodies but if you
were to delay it is quite possible they will chime in since one was
specifically interested in this sort of function.

The amount of changes required to support CH cannot fully be ascertained
until more of the the [Todo]s are filled in with Dave's draft, but I
don't imagine the work would be much more than:

 - specifying how to initiate the connection and if necessary turn it
 - the identity used for requests received from command generators that
   did not initiate the connection along with potential prepopulating
   of various tables
 - an appendix of how the SNMP-TARGET-MIB would be populated
 - a discussion on when to initiate connections and what to do when
   they fail (mind you this is needed anyway regardless of CH)
 - security considerations involving firewalls, blocking, etc.
 - possibly one additional table describing the state of SSH peer
   connectivity (which probably wouldn't be bad to have anyway).

Decide for yourself if you think this is a substantial amount of text,
but I won't leave it to your imagination for long.  I will attempt this
week to post a derivative of the draft that Dave is working on to give
people an idea of what the changes would be.

Again it's difficult to diff an incomplete specification.

Eliot

>>>>>>>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:
> 
>

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 13 Sep 2005 02:36:26 +0200

Eliot,

At the SBSM and ISMS BoF sessions at IETF 58 and 60 the need for
integrating SNMP into existing security frameworks was extensively
discussed.  Wes presented the issue at NANOG and performed a survey
among operators.  The output of all this work is the idenitfication
of a well founded general requirement for working on the integration
of SNMP into existing security frameworks in an IETF working group.

Now you claim that solving this issue is technically wrong without
considering a different problem that you call "call home".  Rather
you request adding the issue of solving the "call home" to the ISMS
charter.

However, nobody raised this issue at the ISMS BoFs nor has the
issue been discussed in depth in the OaM area.  But we should have
such a discussion before adding the issue to any IETF WG charter.
It looks like a good topic for a BoF session in the OaM area.
There we could find out the relevance of the problem and discuss
requirements for potential solutions.  Also there we can identify
which working group would be the right one to deal with the issue.

But until then, I propose that we let the ISMS group work on solving
its original problem.

Thanks,

    Juergen

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 12 Sep 2005 19:02:12 -0400

Hi,

As primary editor of the SSH draft (SSHSM), I spoke with Eliot last
week. I agree that it is difficult for him to develop a reasonable
proposal that piggybacks on the SSH draft, because the SSH draft is so
incomplete.

I am not convinced that SNMP needs to add a new call-home (CH)
functionality, nor that this feature is needed in SNMP now, but there
is a danger that CH might never be possible if we don't consider its
impact on the SSHSM model before SSHSM is cast in stone. If it
complicates the SSHSM model, I would prefer to not include it; a new
model could be developed to replace or supplement the SSHSM model if
demand increases for this functionality.

I recommended to Eliot that he contribute some text for the SSH
document, describing the CH functionality and proposed elements of
procedure, that I could include as an appendix to the SSHSM document
so the WG could review his proposal, and then the WG could decide
whether it should remain as an appendix, be incorporated into the SSH
document, be split out as a separate document, or be abandoned
altogether. I felt this was a reasonable alternative to making the
decision whether CH is or is not in scope at this time. He has not yet
had a chance to develop the text and send it to me. 

David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Eliot Lear
> Sent: Monday, September 12, 2005 3:53 PM
> To: Sam Hartman
> Cc: IETF Discussion; [email-masked]; [email-masked]
> Subject: [Isms] ISMS charter broken- onus should be on WG to fix it
> 
> Sam,
>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 13 Sep 2005 08:38:30 +0200

Juergen,

Wes received the obvious feedback that operators find SNMP unusable with
the USM model because they cannot integrate it with their existing
security infrastructures and there is no denying that this is a real
problem.  But this is NOT the only problem operators face with SNMP.

While the group focused on UDP-based solutions it made no sense to raise
concerns about firewall and NAT traversal, because in my opinion UDP
traversal would likely be no different for ISMS or non-ISMS.  With TCP
and SSH in particular, the group can reasonably deal with the problem
with very little additional work, as I described.  Because it can, it
should.

In other words, firewall/NAT traversal has always been a problem, but
the choice of either SSH or BEEP could easily provide a means to address it.

People have suggested a BoF on this subject.  I am perfectly happy to
hold a BoF in November on this subject if the WG and IESG are adamant
that this work be done elsewhere.  I suggest that it occur adjacent to
the ISMS working group, so that people understand just the sort of
changes that will be required between ISMS and this other thing.

I would also agree with Dave that if the necessary work for CH turns out
to be onerous in ISMS the the WG should reconsider.  I just don't
envision the premise of that statement being true.

Eliot

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 13 Sep 2005 11:05:49 -0400

Hi,

Personally, I'd rather see the issue of working through NATs and
firewalls solved at the SSH level, and then SNMP and other SSH-using
applications, such as Netconf and CLI, could use the solution in a
consistent manner. 

The O&M community has gone through a multi-year effort to better
understand operators' needs in network management. That effort started
years ago at an Open O&M meeting. 

Bert and David are tentatively planning another Open O&M meeting at
IETF64. Since the O-side draws more operators than the M-side of O&M,
it might be worthwhile asking the operators that are present at that
meeting if they believe this is an important problem to solve at the
SNMP level, and whether they would prefer it be solved at the SSH
level.

David Harrington
[email-masked]

> [mailto:[email-masked]] On Behalf Of Juergen Quittek
> Sent: Monday, September 12, 2005 8:36 PM
> To: Eliot Lear; Sam Hartman
> Cc: [email-masked]; IETF Discussion; [email-masked]
> Subject: Re: [Isms] ISMS charter broken- onus should be on WG 
> to fix it
> 
> Eliot,
>

---

From: Sam Hartman <[email-masked]>
Date: Tue, 13 Sep 2005 14:37:23 -0400

>>>>> "David" == David B Harrington <[email-masked]> writes:

    David> Hi, As primary editor of the SSH draft (SSHSM), I spoke
    David> with Eliot last week. I agree that it is difficult for him
    David> to develop a reasonable proposal that piggybacks on the SSH
    David> draft, because the SSH draft is so incomplete.

    David> I am not convinced that SNMP needs to add a new call-home
    David> (CH) functionality, nor that this feature is needed in SNMP
    David> now, but there is a danger that CH might never be possible
    David> if we don't consider its impact on the SSHSM model before
    David> SSHSM is cast in stone. If it complicates the SSHSM model,
    David> I would prefer to not include it; a new model could be
    David> developed to replace or supplement the SSHSM model if
    David> demand increases for this functionality.

    David> I recommended to Eliot that he contribute some text for the
    David> SSH document, describing the CH functionality and proposed
    David> elements of procedure, that I could include as an appendix
    David> to the SSHSM document so the WG could review his proposal,
    David> and then the WG could decide whether it should remain as an
    David> appendix, be incorporated into the SSH document, be split
    David> out as a separate document, or be abandoned altogether. I
    David> felt this was a reasonable alternative to making the
    David> decision whether CH is or is not in scope at this time. He
    David> has not yet had a chance to develop the text and send it to
    David> me.

I completely agree that having Eliot and other interested parties work
on how technical details of CH would work for ssh is a good idea.

I also agree that having it be an appendix in the document is fine for
now.

I was hoping that Eliot would go forward in this direction; in my
original message ruling CH out of scope I aske Eliot to work with the
ssh document editor to see how CH might work.

--Sam

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 13 Sep 2005 14:43:45 -0700

Eliot> Wes received the obvious feedback that operators find SNMP
Eliot> unusable with the USM model because they cannot integrate it
Eliot> with their existing security infrastructures and there is no
Eliot> denying that this is a real problem.  But this is NOT the only
Eliot> problem operators face with SNMP.

FYI, there was a "other comments" field in the survey that the
operators filled out.  I just went back and reviewed everything
entered into that space and no one asked for anything like the CH
functionality, nor did they even mention NATs or firewalls at all.

That being said, that wasn't the point of the survey and I do think
the problem shouldn't be forgotten.  I think we'd be stupid to let the
work go forward and do something that deliberately prevented CH
functionality from being usable in the ISMS/SSH draft.  However,
everything needs to be weighed and I do think we should make sure it's
possible till we run into a problem.  At that time we'd have to
evaluate the choices to decide which was more important (the potential
problem being unknown at this time of course).

I'm not sure the charter needs to explicitly state that we must
consider call home support.  It sounds like there is enough energy to
make sure we don't blow it.  I would strongly object to anything that
says we must support it, because as has been stated many times "that's
not the point of the WG".  At the same time, I think we'd be idiots
not to at the very least leave room for it (but then, I think we're
not being wise for dropping the consideration of a UDP solution too, so...)

-- 
Wes Hardaker
Sparta, Inc.

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 14 Sep 2005 19:28:24 -0700 (PDT)

On Wed, 7 Sep 2005, The IESG wrote:
> A modified charter has been submitted for the Integrated
> Security Model for SNMP (isms) working group in the Security
> Area of the IETF.
...
> In order to leverage the authentication information already
> accessible at managed devices, the new security model will
> use the SSH protocol for message protection, and RADIUS for
> AAA-provisioned user authentication and authorization.
> However, the integration of a transport mapping security model
> into the SNMPv3 architecture should be defined such that it is
> open to support potential alternative transport mappings to
> protocols such as BEEP and TLS.
> 
> The new security model must not modify any other aspects of
> SNMPv3 protocol as defined in STD 62 (e.g., it must not create
> new PDU types).

If (as I have gathered from the discussion over the past few days)
the last sentence quoted above means that it is out of scope for the
working group to even consider solutions that allow agents and
managers to work on either side of firewalls or NATs, then I think
that the charter is drawn too narrowly and should be revised.
Indeed, I think that it should be an explicit goal (if not a
requirement) for the solution to work even when one of the parties
(agent or manager) is unable to accept incoming TCP connections.
That issue will have to be addressed eventually, and it is better
for implementors to go through the churn once rather than twice.

Mike Heard

P.S.  Note that I am using the words "agent" and "manager" in the
traditional sense, i.e., to mean "notification originator + command
responder" and "notification receiver + command generator"
respectively.