IETF Logo Mail Archive

Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts

Paul Wouters <paul@cypherpunks.ca> Tue, 04 March 2014 09:59 UTC

Return-Path: <paul@cypherpunks.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB921A04A4 for <ipsec@ietfa.amsl.com>; Tue, 4 Mar 2014 01:59:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgPuVnkETrPU for <ipsec@ietfa.amsl.com>; Tue, 4 Mar 2014 01:59:29 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 92D2F1A049D for <ipsec@ietf.org>; Tue, 4 Mar 2014 01:59:29 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 31A65800AF; Tue, 4 Mar 2014 04:59:26 -0500 (EST)
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s249xPGt002698; Tue, 4 Mar 2014 04:59:25 -0500
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Tue, 04 Mar 2014 04:59:25 -0500
From: Paul Wouters <paul@cypherpunks.ca>
X-X-Sender: paul@bofh.nohats.ca
To: RJ Atkinson <rja.lists@gmail.com>
In-Reply-To: <E8A7A614-C2D5-4820-A0AF-1B1970C6C177@gmail.com>
Message-ID: <alpine.LFD.2.10.1403040457540.1910@bofh.nohats.ca>
References: <66A2E597-43D4-4403-9FF8-D8D13F35E958@gmail.com> <alpine.LFD.2.10.1403031743030.4233@bofh.nohats.ca> <E8A7A614-C2D5-4820-A0AF-1B1970C6C177@gmail.com>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Qs9e0c7FFH-dI90RhtUb9smIMzk
Cc: IPsec ME WG List <ipsec@ietf.org>
Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Mar 2014 09:59:31 -0000

On Tue, 4 Mar 2014, RJ Atkinson wrote:

>> What meaning has "protecting" those bits? Endpoint A and B protect
>> something by cryptography, but any router in the middle can't trust
>> those signatures anyway. So I don't see how AH is different from
>> ESPinUDP where you set those options in the UDP header. These are
>> not "protected" but the router can't verify the crypto anyway.
>
> At least some deployed routers in the middle in some deployments
> ARE able to validate and therefore trust the AH values (and trust
> that the IP options present were placed there by the sender).  This
> was ALWAYS something that was designed-in to AH (RFC-1826, Section 1.1).
> Some other kinds of middleboxes (e.g. some firewalls) also can do this.

I was not aware of such deployments. Thanks for the information.

Paul

v2.23.0 | Report a Bug | By Email