==============================================
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
draft-lear-callhome-description-03.txt


----------------
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?

Eliot:
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
basis?
-> 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.

Elior 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