Re: [Call-home] draft now posted; BoF?

Eliot Lear <> Tue, 27 September 2005 09:34 UTC

Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1EKBqj-0005QP-7b; Tue, 27 Sep 2005 05:34:09 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1EKBqh-0005QI-Gt for; Tue, 27 Sep 2005 05:34:07 -0400
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id FAA25742 for <>; Tue, 27 Sep 2005 05:34:05 -0400 (EDT)
Received: from ([] by with esmtp (Exim 4.43) id 1EKBxv-0007aE-H5 for; Tue, 27 Sep 2005 05:41:35 -0400
Received: from ([]) by with ESMTP; 27 Sep 2005 02:33:58 -0700
X-IronPort-AV: i="3.97,149,1125903600"; d="scan'208"; a="345868125:sNHT32646508"
Received: from ( []) by (8.12.10/8.12.6) with ESMTP id j8R9Xs4V027949; Tue, 27 Sep 2005 02:33:55 -0700 (PDT)
Received: from [] ( []) by (8.12.11/8.12.10) with ESMTP id j8R9jeJF016956; Tue, 27 Sep 2005 02:45:41 -0700
Message-ID: <>
Date: Tue, 27 Sep 2005 11:33:52 +0200
From: Eliot Lear <>
User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
Subject: Re: [Call-home] draft now posted; BoF?
References: <> <20050926210654.GA3067@boskop.local>
In-Reply-To: <20050926210654.GA3067@boskop.local>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=2322; t=1127814342; x=1128246542; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding;;; z=Subject:Re=3A=20[Call-home]=20draft=20now=20posted=3B=20BoF?| From:Eliot=20Lear=20<>| Date:Tue,=2027=20Sep=202005=2011=3A33=3A52=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=k8iD2ezji/cW+CercEs+TtThgBvvJlQfTKe+Msm/6Dx+8wvMV/kLoxURwDT5qlGenl21/2Ub AQEs21vvT0r4AyFw3m7SjMYDG3TbEN7KEuQooskk07bgn2DER2TVQKluo3MPJR3wRwZMILA84dd BNDBWt25v5wC7KWYbja6etbU=
Authentication-Results:;; dkim=pass ( message from verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Discussion of issues relating to &quot; call home&quot; functionality and firewall traversal" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Juergen Schoenwaelder wrote:
> On Mon, Sep 26, 2005 at 03:46:29PM +0200, Eliot Lear wrote:
>>A draft is now posted - draft-lear-callhome-description-00.txt.  It
>>doesn't yet have much in the way of SNMP specifics but I am working on
>>that now.
> I am not sure what the scope of your efforts here are. Do you limit
> this in scope to the management domain (which is somewhat implied by
> talking about managers and agents) or do you want to address the more
> general question of how to reverse connection establishment from the
> inside to the outside. 

I've been asked to consider the broader architectural issues (if any),
but my interest is in network management as well.  It would be good if
someone could flag issues they see as broader than the area of
management if I miss them.

> In any case, I would like to discuss this issue
> not only in the context of SNMP, but at least also consider netconf,
> where the required to implement transport mapping also does not
> provide call home at the moment.
> Personally, I am concerned about the security considerations. I would
> very much prefer a solution where the authenticated identities and the
> way they are authenticated remain the same, regardless whether I am
> using call-home or not. Now, it may turn out that this is not feasible
> to achieve. If that is the case, these findings need to be documented
> somewhere.

I am not sure this is a problem with the notion call home, but perhaps
with mechanisms used to achieve it.  For instance, BEEP today supports
either side initiating a connection as well as mutual authentication via
TLS.  In the case of SNMP, therefore, there would be a mapping from
securityName to X.509 subject (amongst other things), either directly or

But I wonder whether we should mandate such a requirement.  Also if we
are making use of substrates such as SSH, BEEP, or for that matter HTTP,
how we structure those interfaces.

In a practical sense, a service provider already provides a username and
password to an end user.  It would seem impractical for the user to
provide a username and password back to the service provider when an
X.509 certificate would do the job.

>>Did I miss architectural issues in the draft?
> I only had a very quick read. For me, the really interesting issue is
> to figure out how much security protocols like SSH or TLS actually
> [rely] on the connection initiation procedure or whether the
> client/server roles can be "turned" before the security protocols do
> their work. In other words, I would like to know whether some
> extensions to say SSH can solve most of the issues with call home
> support in ISMS and NETCONF.

I'm not quite sure what you're asking for.  Are you suggesting, for
instance, that the initiator have a host key and the listener make use
of a user key?


Call-home mailing list