Re: [tcpm] [BULK] TCP-AO: A position on NAT-T support

"Caitlin Bestler" <> Tue, 02 September 2008 22:08 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id E0ED83A69A9; Tue, 2 Sep 2008 15:08:41 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 847DC3A69A9 for <>; Tue, 2 Sep 2008 15:08:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ECE9gqstYNm0 for <>; Tue, 2 Sep 2008 15:08:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A79C13A67FE for <>; Tue, 2 Sep 2008 15:08:39 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 02 Sep 2008 18:08:23 -0400
Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD770432FBD6@nekter>
In-Reply-To: <>
Thread-Topic: [BULK] [tcpm] TCP-AO: A position on NAT-T support
Thread-Index: AckKQnQ1dN7b/e4iTI2w136xvHCzewDBVatA
References: <>
From: Caitlin Bestler <>
To: "Gregory M. Lebovitz" <>,
Subject: Re: [tcpm] [BULK] TCP-AO: A position on NAT-T support
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Gregory Lebovitz wrote:
> 2. Not Every Protocol MUST Fill Every Requirement
> The IETF MUST give every app a way to simultaneously traverse NATs
> AND be authenticated. However, it does not necessarily follow that
> every protocol must have a way to simultaneously provide apps with
> NAT-T and authentication. As long as at least one or more protocols
> does allow a specific app to accomplish NAT-T + Authentication, we
> have succeeded. In other words, we need not burden every protocol
> with every use case. In the case of TCP connections, IKE+ESP can
> simultaneously provide NAT-T and Authentication, though at a costs of
> more processing and layering and configuration complexity.

I agree.

TCP-AO should be kept simple and focused very specifically
on being a drop-in replacement for TCP-MD5. There should be
no expansion of its functionality unless it can be shown that
the additional application scenarios are NOT served by other
security solutions, and that the changes to the other
services would not be practical.

In my opinion that criteria would not be met by TCP-AO as
a whole, if there were not already applications finely tuned
to this specific security model. But those are *existing*
applications. New features are not used by existing applications,
and so the applications are free to use solutions other than
TCP-AO. We should encourage them to do so, rather than expanding
TCP-AO to be yet another "full service" security solution.

tcpm mailing list