[Call-home] new draft -03 coming out...

Eliot Lear <lear@cisco.com> Wed, 19 October 2005 04:42 UTC

Received: from localhost.localdomain ([] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES5n1-0006KO-P9; Wed, 19 Oct 2005 00:42:59 -0400
Received: from odin.ietf.org ([] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES5n0-0006Jk-Dn for call-home@megatron.ietf.org; Wed, 19 Oct 2005 00:42:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19843 for <call-home@ietf.org>; Wed, 19 Oct 2005 00:42:49 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES5ye-0006P4-TW for call-home@ietf.org; Wed, 19 Oct 2005 00:55:02 -0400
Received: from sj-core-4.cisco.com ([]) by sj-iport-5.cisco.com with ESMTP; 18 Oct 2005 21:42:33 -0700
X-IronPort-AV: i="3.97,229,1125903600"; d="scan'208"; a="221462232:sNHT665883590"
Received: from imail.cisco.com (imail.cisco.com []) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j9J4gVUw004887 for <call-home@ietf.org>; Tue, 18 Oct 2005 21:42:31 -0700 (PDT)
Received: from [] (ams-clip-vpn-dhcp83.cisco.com []) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j9J4qvRR012878 for <call-home@ietf.org>; Tue, 18 Oct 2005 21:52:58 -0700
Message-ID: <4355CEB6.1090605@cisco.com>
Date: Wed, 19 Oct 2005 06:42:30 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 1.4.1 (Macintosh/20051006)
MIME-Version: 1.0
To: call-home@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=914; t=1129697578; x=1130129778; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:new=20draft=20-03=20coming=20out...| From:Eliot=20Lear=20<lear@cisco.com>| Date:Wed,=2019=20Oct=202005=2006=3A42=3A30=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=H649X7cM6Rxxy+G355F9p5/nXkFBsnI/AtFQBKiB6EPSssPqknDeLbSb7BHbKajIhHvTgteF PThARseeaHPTC7GHkns/3JChm1V5LJ8RmsTUV9QV9SGZjLgI8NImclO0lR/SE2UTXnIDlw3t21l fyXhZD6Ee9/fsMgs5KVSU6Bs=
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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit
Subject: [Call-home] new draft -03 coming out...
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

Hi There,

There will be a new draft-lear-callhome-description-03 in the next day 
or so.  The key changes are these:

  - I've added a section discussing naming.  The devices that use
    CH often have a problem with stable names from a DNS perspective.
    Not always, but often.  So people who use or implement CH need to
    think about this.  This could cause us to wade into old NSRG
    territory, but there was a recent paper (Braden et. al.?) that
    discusses application naming that may be more relevant.
    Anyone got a cite for that?

  - I've added an additional example that demonstrates how one could
    use CH to gain interactive access to an agent behind a firewall.
    Now, this could be a good thing or a bad thing.  It's a good thing
    for authorized access and a bad thing for unauthorized access ;-)
    This example exposes potentially overly strong language in
    draft-ietf-secsh-connect in which they say that clients SHOULD
    reject "session" service.  Yes, they should if they're not prepared
    to deal with the auth/authz issues.  But if they are, then it
    should be okay.  This latter case exposes the naming issue.



Call-home mailing list