IETF Logo Mail Archive

Re: [RPSEC] Discontiguous Deployment (Show of Hands)....

sandy@tislabs.com (Sandy Murphy) Wed, 28 February 2007 17:45 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMSrc-0000Uz-Ka; Wed, 28 Feb 2007 12:45:16 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMSra-0000B4-Kl for rpsec@ietf.org; Wed, 28 Feb 2007 12:45:14 -0500
Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMSrY-0006Rv-T5 for rpsec@ietf.org; Wed, 28 Feb 2007 12:45:14 -0500
Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l1SHh5Ew024621; Wed, 28 Feb 2007 12:43:05 -0500 (EST)
Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAA2UaO4V; Wed, 28 Feb 07 12:42:06 -0500
Received: by pecan.tislabs.com (Postfix, from userid 2005) id E53EC3F443; Wed, 28 Feb 2007 12:41:25 -0500 (EST)
To: curtis@occnc.com, ttauber@1-4-5.net
Subject: Re: [RPSEC] Discontiguous Deployment (Show of Hands)....
In-Reply-To: <Pine.LNX.4.64.0701300746260.14084@m106.maoz.com>
Message-Id: <20070228174125.E53EC3F443@pecan.tislabs.com>
Date: Wed, 28 Feb 2007 12:41:25 -0500 (EST)
From: sandy@tislabs.com (Sandy Murphy)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: rpsec@ietf.org, riw@cisco.com
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing Protocol Security Requirements <rpsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>, <mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/rpsec>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>, <mailto:rpsec-request@ietf.org?subject=subscribe>
Errors-To: rpsec-bounces@ietf.org

I got to thinking about:

Tony Tauber said:

>>   o  In an environment where secured service is in the process of
>>      being deplyed a mechanism MUST exist to support a transition
>>      free of service interruption.
>
>I think the original bullet is about something else and still has
>merit, but I like your addition.

If a secured service requires a change in the router software,
would it not then require a service interrruption to upgrade the software?
Is this stipulation intended to outlaw any and all in-band secured service?
Would a replacement for the TCP MD5 method, for example, be outlawed?

Just how broad a "free of service interruption" requirement is this?

--Sandy

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec

v2.8.7 | Report a Bug | By Email