[Call-home] minutes, take 2

Eliot Lear <lear@cisco.com> Wed, 07 December 2005 08:04 UTC

Received: from localhost.cnri.reston.va.us ([] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjuHw-0005Rv-TL; Wed, 07 Dec 2005 03:04:32 -0500
Received: from odin.ietf.org ([] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjuHv-0005QM-Em for call-home@megatron.ietf.org; Wed, 07 Dec 2005 03:04:31 -0500
Received: from ietf-mx.ietf.org (ietf-mx []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28477 for <call-home@ietf.org>; Wed, 7 Dec 2005 03:03:39 -0500 (EST)
Received: from sj-iport-5.cisco.com ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejuda-0005QB-9T for call-home@ietf.org; Wed, 07 Dec 2005 03:26:54 -0500
Received: from sj-core-5.cisco.com ([]) by sj-iport-5.cisco.com with ESMTP; 07 Dec 2005 00:04:20 -0800
X-IronPort-AV: i="3.99,223,1131350400"; d="scan'208"; a="238185814:sNHT32422182"
Received: from imail.cisco.com (imail.cisco.com []) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jB784IQK010952 for <call-home@ietf.org>; Wed, 7 Dec 2005 00:04:19 -0800 (PST)
Received: from [] (ams-clip-vpn-dhcp4111.cisco.com []) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id jB78BgLd016091 for <call-home@ietf.org>; Wed, 7 Dec 2005 00:11:42 -0800
Message-ID: <43969780.7070602@cisco.com>
Date: Wed, 07 Dec 2005 09:04:16 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 1.5 (Macintosh/20051025)
MIME-Version: 1.0
To: call-home@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=5125; t=1133943103; x=1134375303; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:minutes,=20take=202| From:Eliot=20Lear=20<lear@cisco.com>| Date:Wed,=2007=20Dec=202005=2009=3A04=3A16=20+0100| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=EXUABcz/aC9soR+ES3b13pus0O5PCWzQrvK8z/doxUtW3JgCdB2nJRjj2jKVgKhYFXeiQ0rD aYslWkYA9Fli08GleBnSed76X3vLdmXMHvQBOn68xBIOOibkLj75w9X/Zfk5B8yaCmeva9iATxg aT2S26lIbifGqNmq9Axnf53Q=
Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bf422c85703d3d847fb014987125ac48
Content-Transfer-Encoding: 7bit
Subject: [Call-home] minutes, take 2
X-BeenThere: call-home@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Discussion of issues relating to &quot; call home&quot; functionality and firewall traversal" <call-home.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/call-home>, <mailto:call-home-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/call-home>
List-Post: <mailto:call-home@ietf.org>
List-Help: <mailto:call-home-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/call-home>, <mailto:call-home-request@ietf.org?subject=subscribe>
Sender: call-home-bounces@ietf.org
Errors-To: call-home-bounces@ietf.org

I've checked the minutes with the tape as far as it goes, (we got cut
off the last few minutes).  This also includes some spelling
corrections, and corrected names.

Minutes of the callhome BoF session at IETF 64
Tuesday November 8, 18:50 h - 19:50 h

Reversing traditional Client/Server Connection Model BoF

Chair: Eliot Lear   <lear@cisco.com>;

0. Agenda Bashing
1. Motivation / Description (Eliot)
2. Tunneling / HIP Approaches (Pekka)
3. Existing Work (ICE/STUN/...) (Jonathon)
4. (In)Applicability for ISMS (Dave H.)
5. Discussion / Close

Discussed Internet drafts

Simple Firewall Traversal Mechanisms and Their Pitfalls

1. Call Home Description (callhome-1.pdf, Eliot Lear)

Eliot presented draft-lear-callhome-description-03.txt on
'Simple Firewall Traversal Mechanisms and Their Pitfalls'.

Eliot pointed out the problem that many devices behind NATs and
firewalls are inaccessible from the outside. The problem space
further includes devices that are intermittently connected.

Call home is a connection model reversing the role of client and
server when establishing a connection. This requires that the agent
needs to know whom to contact and that each side must know the roles
of its own and of the other party.

Authentication and authorization may be different from traditional
connection direction. DNS for naming might become a problem.

2. Calling Home - The Big Picture (callhome-3.pdf, Pekka Nikander)

Pekka claims that the idea of end-to-end is dead in today's Internet.
For the future he predicts the integration of mobility, security and
multi-homing.  He discussed two approaches - HIP and SHIM6 - that make
use of a shim layer. The shim approach is introducing a new layer within
the IP stack separating higher layer IP addresses for identification from
lower layer IP addresses for routing. It might be the first step of
a long process toward future end-to-end networking.

He suggested to keep the bigger picture in mind when reasoning about
call home.

3. Calling Home - Call Home and Existing NAT Traversal Work
  (callhome-4.pdf, Jonathan Rosenberg)

Jonathan described the call home problem for four fundamental protocol
operations: connection, registration, keepalive, messaging.
He explained how call home is handled in the SIP world as described
in draft-ietf-sip-outbound.  He also discussed how naming is important.

4. Why Call Home should not be done as part of ISMS
  (callhome-5.pdf, David Harrington)

David stated that the call home goal is not clear.
He said that call home is not widely deployed and not a common feature.
Therefore, it does not fit into the ISMS work that tries to
integrate existing SNMP with existing security infrastructures.

Call home does not solve an SNMP problem or a network management
problem, it solves a transport problem solves a transport problem.
There are existing SNMP solutions: engine ID, proxies, MIDCOM MIB.
Demand for work on call home is lacking in the SNMP world.

Call home and ISMS can work independently.

Keith McCloghrie:
The fundamental issue is that because SNMP is going to SSH it is
changing from a datagram based approach to a session based approach.
Regardless of NAT issues.  Consider the case of the cold start trap.
[Who starts the session for that trap?]

Juergen Quittek:
Do you see a use case and a need for call home?

David Harrington:
Yes, but not specifically for SNMP. It should be solved in general.

5. Discussion (moderated by Eliot Lear)

Bill Sommerfeld:
Certain communication modes are symmetric.  I do not see the reversal
of direction as a show stopper. Who is initiating is up to the application.
The existing SSH can be made to do what you want.

David Perkins:
SNMP security is based on user name. If you reverse the direction,
which ID do you use for authentication?

The host Identity should be used.

David Harrington:
Host isn't authorized to access MIB objects.  Users are.

Eliot Lear:
How many in the room think it would be a useful work item to deal with
for network management?
-> ("saw consensus")

Jean-Francois Mule from Cable Labs:
We manage millions of devices via SNMP.  We're looking now looking at SIP.
How to manage millions of SIP devices behind NATs? Yes you can do call
home.  For cable networks it is broader than SNMP and very useful.

Bert Wijnen:
SNMPv3 can send a coldstart trap, but this does not mean it addresses
the call home problem, because the device may still not be reachable
from the manager.  The problem is not specific to SSH.

Dave Harrington:  Proxy could solve the problem.

Eliot Lear:
Should the problem be addressed in the context of SNMP ?
-> one hand raised

Eliot Lear:
Should it be addressed more generally?
-> many hands raised ("overwhelming").

Eliot Lear:
Do we need an IETF-wide approach?

-> several hands raised  ("not overwhelming").

Eliot Lear:
How many people believe it should NOT be addressed on an IETF-wide
-> Only Eliot

Jonathan Rosenberg:
We rather need application-specific solutions.  For example the
association between SNMP agents and IP addresses does not work anymore
in the presence of NATs.

David Harrington:
We identify the device using a contextEngine ID and we talk to the
device with the IP address.  If the device isn't reachable in the
first place, autodiscovery will not work.

Eliot Lear:
The problem is not just limited to NAT traversal, but also concerns
intermittently connected devices.

Keith Moore:
We need a transition path away from NATs.
NATs produce more and more headache and less and less value.
Call home just addresses half of the NAT problem.
We need a WG to figure out how to migrate to NAT-free solutions.

Eliot Lear:
Do people think we should work on a BCP approach?

-> several hands raised

Eliot Lear:
Or not?

-> one hand raised

Eliot Lear:
Do we need more investigation?

-> many hands raised

Eliot Lear:
How many people think the investigation should be done in a WG?

-> 3 hands raised

Call-home mailing list