IETF Logo Mail Archive

Re: [karp] Gen-ART Telechat Review of draft-ietf-karp-routing-tcp-analysis-06

Nick Hilliard <nick@inex.ie> Wed, 19 December 2012 23:21 UTC

Return-Path: <nick@inex.ie>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72CA721F892A; Wed, 19 Dec 2012 15:21:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.54
X-Spam-Level:
X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynRRuOmsL7dI; Wed, 19 Dec 2012 15:20:58 -0800 (PST)
Received: from mail.acquirer.com (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 38D9221F8899; Wed, 19 Dec 2012 15:20:55 -0800 (PST)
X-Envelope-To: karp@ietf.org
Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100:41e8:aae1:8461:f339]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id qBJNJ9VM040188 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 19 Dec 2012 23:19:15 GMT (envelope-from nick@inex.ie)
Message-ID: <50D24BD1.4070801@inex.ie>
Date: Wed, 19 Dec 2012 23:20:49 +0000
From: Nick Hilliard <nick@inex.ie>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Anantha Ramaiah <ananth@nttmcl.com>
Subject: Re: [karp] Gen-ART Telechat Review of draft-ietf-karp-routing-tcp-analysis-06
References: <AEDD0F1A-EA31-4C3A-B1BF-BD16C9196740@nostrum.com> <50D0EA56.3050308@inex.ie> <50D0ED83.3090700@joelhalpern.com> <CAFZUbhenPyaDoknGafGd4SOXOUVo5VpbohjC8D5rB21iB0v1xQ@mail.gmail.com>
In-Reply-To: <CAFZUbhenPyaDoknGafGd4SOXOUVo5VpbohjC8D5rB21iB0v1xQ@mail.gmail.com>
X-Enigmail-Version: 1.4.6
X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804
X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3
X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee
X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24.
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "draft-ietf-karp-routing-tcp-analysis.all@tools.ietf.org" <draft-ietf-karp-routing-tcp-analysis.all@tools.ietf.org>, "ietf@ietf.org List" <ietf@ietf.org>, "karp@ietf.org" <karp@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Dec 2012 23:21:04 -0000

On 18/12/2012 23:15, Anantha Ramaiah wrote:
> Also TCP MD5 with periodic key rollover can make the life harder for TCP
> MD5 based collision attacks.

there is no facility in rfc 2385 for automatic key rollover, which means
that any key changes must be done manually.  I've come across gratuitous
key rollover happening exactly once in my career: namely where (as far as I
understand) a particular company had used the same MD5 key for all ebgp
peering sessions worldwide.  They eventually decided that this wasn't such
a good idea and subsequently changed keys whenever they changed routers /
bgp sessions / did port upgrades / etc.  Other than that, I've never come
across a case of someone wanting to proactively change a session key
because it seemed to be a good idea.  Just sayin'.

Nick

v2.23.0 | Report a Bug | By Email