[Softwires] ALG section in draft-ietf-softwire-dual-stack-lite-06

"Dan Wing" <dwing@cisco.com> Wed, 23 February 2011 16:18 UTC

Return-Path: <dwing@cisco.com>
X-Original-To: softwires@core3.amsl.com
Delivered-To: softwires@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 906353A68FE for <softwires@core3.amsl.com>; Wed, 23 Feb 2011 08:18:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.583
X-Spam-Level:
X-Spam-Status: No, score=-110.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEo3UZOR0cgh for <softwires@core3.amsl.com>; Wed, 23 Feb 2011 08:18:27 -0800 (PST)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id D06C03A67A1 for <softwires@ietf.org>; Wed, 23 Feb 2011 08:18:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1544; q=dns/txt; s=iport; t=1298477955; x=1299687555; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=4Oqi9ryhpmZosXiI3i+c6ZyKcs7GF0BzEv5W062OkmA=; b=UzFbqFw0a7Wok5b/Z52irQmIvnykvAnF9OkG/+dMYO8HlXcOCb6xoPwJ NfhfxibXqbvEJCUm0w4+PZyeOkKfhKzZI/4f/f21q7mUczuK9X+sDlnJe 8ZaQyM496tTekPQoORqwwTIRuicquGlNiLEGdHKkTf/CzxyrmvzgfHxqY 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Al4HAMvBZE2rR7Ht/2dsb2JhbACYDIEmjGdzoGKbeIVeBIUN
X-IronPort-AV: E=Sophos;i="4.62,212,1297036800"; d="scan'208";a="314290753"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 23 Feb 2011 16:19:15 +0000
Received: from dwingWS ([10.32.240.195]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1NGJEQv018378; Wed, 23 Feb 2011 16:19:15 GMT
From: Dan Wing <dwing@cisco.com>
To: softwires@ietf.org
Date: Wed, 23 Feb 2011 08:19:14 -0800
Message-ID: <19e901cbd375$69d56c20$3d804460$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcvTdWmUtTr97IytTgewiqrOo8O3HA==
Content-Language: en-us
Cc: draft-ietf-softwire-dual-stack-lite@tools.ietf.org
Subject: [Softwires] ALG section in draft-ietf-softwire-dual-stack-lite-06
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Feb 2011 16:18:28 -0000

http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-06 says:

   8.3. Application Level Gateways (ALG)

   The AFTR should only perform a minimum number of ALG for the classic
   applications such as FTP, RTSP/RTP, IPsec and PPTP VPN pass-through
   and enable the users to use their own ALG on statically or
   dynamically reserved ports instead.

Comments:

* To my knowledge, this would be the first time IETF suggests using an ALG
in a NAT44 in a standards-track document.

* Both IPsec and PPTP are protocols, not applications.  IPsec is 50
(assuming you mean IPsec ESP, which I'm sure is what was intended) and PPTP
uses protocol 47 (GRE).  Thus, these do not belong in the Application Level
Gateway section.  Rather, IPsec and PPTP should be moved to the previous
section (NAT Conformance) which already mentions other protocols like TCP
and ICMP.

* There aren't specifications describing an ALG for FTP, RTSP, RTP, IPsec,
or PPTP VPN.

* What is "RTSP/RTP"?  Is this trying to say "RTSP, when it is using RTP",
or is it trying to say "RTSP and other uses of RTP".  Text needs to be
clarified.

* IPsec Passthru is pretty common on residential NATs.  However, in a CGN,
IPsec Passthru is difficult when multiple users connect to the same VPN
concentrator.  When that concentrator re-keys a session, the incoming IPsec
SPI changes and there is no simple way to determine which user should
receive that packet.  There are several workarounds to this problem,
including just ignoring it.

-d