RE: [Call-home] draft minutes

["Wijnen, Bert (Bert)" <[e-mail]>]

Eliot,

nits:
- pls check for spelling errors.
- You also made a few "duplicate words or sets of words"

help:
- the gentleman from a cable company was Jean-Francois Mule
  from cablelabs

My comment you recorded:

   Bert Wijnen:
   SNMPv3 can send a coldstart trap, but this does not mean it addresses
   the call home problem.

I was reacting to Keith's comment on "cold start" and the question of
"who would initiate the session". 
First, I think keith also brought up that an agent can send a "cold
start" today and then the manager can start communicating with the agent.
And with SSH such might not be possible/easy.

And so my comment was to make clear that if in the current SNMPv3 world,
if an agent is behind a NAT, then it can send a (UDP) "cold start".
But the Manager can still not setup a "connection" or "manage" the
device behind the NAT, because it may still (certainly not after a
while) be reachable from the manager. So my point is: it is not a
new problem specific to SSH. I agree that SSH may add additional
aspects to the problem.

Bert

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Eliot Lear
> Sent: Thursday, November 17, 2005 22:53
> To: [e-mail]
> Subject: [Call-home] draft minutes
> 
> 
> Dear all,
> 
> Thank you to those who attended the Call Home BoF in 
> Vancouver, BC.  In 
> particular I would like to thank Jonathan Rosenberg, Pekka 
> Nikander, and 
> Dave Harrington for presenting, and Juergen Quittek for 
> taking minutes.
> 
> Attached are those draft minutes.  Please send corrections to me by 
> December 1.
> 
> I look forward to continuing a lively debate.
> 
> Eliot
> 
> ==============================================
> 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   <[e-mail]>
> 
> 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
> the 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. 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 coll home problem for four fundamental protocol
> operations: connection, registration, keepalive, messaging.
> He explained how call home is handled in the SIP world as deswcribed
> in draft-ietf-sip-outbound.
> 
> 
> ----------------
> 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.
> 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 Thornton:
> Certain communication modes are symmetric.  I do not see the reversal
> of direction as an issue. Who is initiating is up to the application.
> 
> 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:
> Agreed.
> 
> Eliot Lear:
> How many in the room think it would be a useful work item to 
> deal with?
> 
> -> several hands raised
> 
> <Gentleman from a Cable Company>:
> 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.
> 
> 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
> 
> Eliot Lear:
> Do we need an IETF-wide approach?
> 
> -> several hands raised
> 
> Eliot Lear:
> Don't we need it?
> 
> -> Eliot's hand raised.
> 
> 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 distinguish a devices IP address from its engine ID.
> 
> 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 
> 

_______________________________________________
Call-home mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/call-home