RE: Service Identity (Re: Machine Identity)

"David Harrington" <ietfdbh@comcast.net> Thu, 28 February 2008 14:02 UTC

Return-Path: <discuss-bounces@ietf.org>
X-Original-To: ietfarch-discuss-archive@core3.amsl.com
Delivered-To: ietfarch-discuss-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 880A73A6EA1; Thu, 28 Feb 2008 06:02:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.19
X-Spam-Level:
X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TN34tacL9-cO; Thu, 28 Feb 2008 06:02:55 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 520413A6C37; Thu, 28 Feb 2008 06:02:55 -0800 (PST)
X-Original-To: discuss@core3.amsl.com
Delivered-To: discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 380B33A6E72 for <discuss@core3.amsl.com>; Thu, 28 Feb 2008 06:02:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WjVzuazq2-a for <discuss@core3.amsl.com>; Thu, 28 Feb 2008 06:02:53 -0800 (PST)
Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id 5E0A63A6BDE for <discuss@apps.ietf.org>; Thu, 28 Feb 2008 06:02:53 -0800 (PST)
Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id v1do1Y0510vp7WLA600s00; Thu, 28 Feb 2008 14:02:17 +0000
Received: from Harrington73653 ([24.128.66.199]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id v22g1Y0044HwxpC8R00000; Thu, 28 Feb 2008 14:02:46 +0000
X-Authority-Analysis: v=1.0 c=1 a=ZM8n86p0LXsA:10 a=f0Xiuc7wd6U21qAg2NEA:9 a=TSYdQdqWoEZAggzdauoA:7 a=fJhfTmCN8wz_ZO4l3394P8moMLsA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA:10 a=gi0PWCVxevcA:10
From: "David Harrington" <ietfdbh@comcast.net>
To: "'Jeroen Massar'" <jeroen@unfix.org>, "'Balazs Lengyel'" <balazs.lengyel@ericsson.com>
References: <20080226130527.GA1404@generic-nic.net> <20080228112318.GA23196@nic.fr> <20080228114656.GD8439@elstar.local> <Pine.SOL.4.64.0802281405360.10117@kekkonen.cs.hut.fi> <20080228124038.GA8852@elstar.local><47C6B37F.2050505@ericsson.com> <47C6BA02.9090000@spaghetti.zurich.ibm.com>
Subject: RE: Service Identity (Re: Machine Identity)
Date: Thu, 28 Feb 2008 09:02:40 -0500
Message-ID: <0aea01c87a12$95cc8df0$0600a8c0@china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Ach6EFQn/k++gC/bSvC6keXuszYZXQAAJ5jA
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
In-Reply-To: <47C6BA02.9090000@spaghetti.zurich.ibm.com>
Cc: discuss@apps.ietf.org
X-BeenThere: discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@ietf.org>
List-Help: <mailto:discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@ietf.org?subject=subscribe>
Sender: discuss-bounces@ietf.org
Errors-To: discuss-bounces@ietf.org

I don't think that works very well.

We can identify the SNMP service, but there might be multiple SNMP
agents running on a device. And since different OSes have different
ideas of processes, it can be difficult to identify different
instances of the same service. (We tried to standardize facility in
the syslog WG, and couldn't come up with a standard across operating
systems.)

In SNMPv3, we developed an identifier to identify each engine, but
users actually prefer to model the network topology using the IP
address, because when dealing with topology maps the purpose is to
manage the devices in the network. 

If a device catches fire, you don't want to search through diagrams of
virtual services; you want to know where the device is so you can put
the fire out. ;-)

As Juergen said, which identifier works best depends on what you are
trying to do, and no single identifier will always be the best choice.

David Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
dharrington@huawei.com


> -----Original Message-----
> From: discuss-bounces@ietf.org 
> [mailto:discuss-bounces@ietf.org] On Behalf Of Jeroen Massar
> Sent: Thursday, February 28, 2008 8:41 AM
> To: Balazs Lengyel
> Cc: discuss@apps.ietf.org
> Subject: Service Identity (Re: Machine Identity)
> 
> Balazs Lengyel wrote:
> > IMHO virtualization, and programs like VmWare are one 
> example where it 
> > is hard to say what are you trying to identify. The 
> physical box or the 
> > virtual machine?
> 
> One should identify the *service*
> 
> That solves all the issues mentioned here.
> 
> The service could be "your p2p app" but also "HTTP host 
> a.example.com" 
> or "HTTP host b.example.com" etc.
> 
> SSH Keys are a good example of this, they identify the SSH 
> service. You 
> can find that service on IPv4 port 22 and IPv6 port 22, maybe on 
> different other IP addresses or other port numbers. Everytime you 
> connect to that service, you can communicate with it using the same 
> public key, as it's private key remains the same. Now if another SSH

> service steals the IP address or port number, you will get a 
> different 
> key to talk with.
> 
> Solving this with HIP, but instead of "Host" making it 
> "Service" based 
> would be great.
> 
> Note that a lot of virtualization is service based, not really host 
> based. For that matter, the larger sites actually only care about 
> services: deploy 1000 HTTP proxies for site X, deploy 1000 
> crawler bots 
> for purpose Z etc. They really can't care less about the host
itself, 
> that is just a place where the service runs.
> 
> Greets,
>   Jeroen
> 
>