2.4.2 Reversing Traditional Client/Server Connection Model (callhome)
NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.
Last Modified: 2005-10-25
Eliot Lear <firstname.lastname@example.org>
Operations and Management Area Director(s):
Bert Wijnen <email@example.com>
David Kessens <firstname.lastname@example.org>
Operations and Management Area Advisor:
Bert Wijnen <email@example.com>
Description of Working Group:
Goals and Milestones:
No Current Internet-Drafts
No Request For Comments
Current Meeting Report
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
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
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.
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?]
Do you see a use case and a need for call home?
Yes, but not specifically for SNMP. It should be solved in general.
5. Discussion (moderated by Eliot Lear)
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.
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.
Host isn't authorized to access MIB objects. Users are.
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.
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.
Should the problem be addressed in the context of SNMP ?
-> one hand raised
Should it be addressed more generally?
-> many hands raised ("overwhelming").
Do we need an IETF-wide approach?
-> several hands raised ("not overwhelming").
How many people believe it should NOT be addressed on an IETF-wide
-> Only Eliot
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.
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.
The problem is not just limited to NAT traversal, but also concerns
intermittently connected devices.
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.
Do people think we should work on a BCP approach?
-> several hands raised
-> one hand raised
Do we need more investigation?
-> many hands raised
How many people think the investigation should be done in a WG?
-> 3 hands raised
Call Home Agenda
Eliot Lear - Call Home Motivation and Description
Pekka Nikander - Bigger Picture, General Solutions, HIP
Jonathan Rosenberg - ICE, STUN, MIDCOM
Dave Harrington - Why Call Home should NOT be a part of ISMS