[BEHAVE] [Errata Held for Document Update] RFC6146 (4756)

RFC Errata System <rfc-editor@rfc-editor.org> Wed, 13 January 2021 14:42 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CBDC3A10A4; Wed, 13 Jan 2021 06:42:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 iF5684on4073; Wed, 13 Jan 2021 06:42:00 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C29E63A0DDD; Wed, 13 Jan 2021 06:42:00 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 96691F40718; Wed, 13 Jan 2021 06:41:50 -0800 (PST)
To: ydahhrk@gmail.com, marcelo@it.uc3m.es, philip_matthews@magma.ca, iljitsch@muada.com
X-PHP-Originating-Script: 1005:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: magnus.westerlund@ericsson.com, iesg@ietf.org, behave@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20210113144150.96691F40718@rfc-editor.org>
Date: Wed, 13 Jan 2021 06:41:50 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/behave/54749haUqSqmCU7NUqR8-q9Fqnk>
Subject: [BEHAVE] [Errata Held for Document Update] RFC6146 (4756)
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/behave/>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jan 2021 14:42:03 -0000

The following errata report has been held for document update 
for RFC6146, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers". 

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid4756

--------------------------------------
Status: Held for Document Update
Type: Technical

Reported by: Alberto Leiva Popper <ydahhrk@gmail.com>
Date Reported: 2016-08-02
Held by: Magnus Westerlund (IESG)

Section: 3.5.3

Original Text
-------------
If the NAT64 filters on its IPv4 interface, then the NAT64 checks
to see if the incoming packet is allowed according to the Address-
Dependent Filtering rule.  To do this, it searches for a Session
Table Entry with an STE source IPv4 address equal to X, an STE
ICMPv4 Identifier equal to i2, and a STE destination IPv4 address
equal to Y.  If such an entry is found (there may be more than
one), packet processing continues.  Otherwise, the packet is
discarded.  If the packet is discarded, then an ICMP error message
MAY be sent to the original sender of the packet.  The ICMP error
message, if sent, has Type 3 (Destination Unreachable) and Code 13
(Communication Administratively Prohibited).

In case the packet is not discarded in the previous processing
steps (either because the NAT64 is not filtering or because the
packet is compliant with the Address-Dependent Filtering rule),
then the NAT64 searches for a Session Table Entry (...)

Corrected Text
--------------
The NAT64 then searches for a Session Table Entry (...)

Notes
-----
The statement "there may be more than one" is incorrect; the triplet (X,i2,Y) constitutes the whole ICMP session's v4 identifier. Considering that, the whole paragraph tends to fall apart.

The point of Address-Dependent Filtering (ADF) is to provide a means to allow or disallow IPv4-started "sibling" connections. If there is an ongoing connection whose binding state is

	BIB entry: (*,*)       <--> (T,t)
	Session: (*,*),(*,*) <--> (T,t),(Z,z)

(Left side is v6, right side is v4. This is the same notation as the RFC; see for example https://tools.ietf.org/html/rfc6146#section-3.5.1; '*' is anything/irrelevant)

Then ADF dictates whether the v4 endpoint is allowed to create the following new session (using the same BIB entry):

	Session: (*,*),(*,*) <--> (T,t),(Z,m)

(where 'z' is not equal to 'm')

ADF works in UDP/TCP because t and z/m are separate variables. This is not the case in ICMP:

	BIB entry: (*,*)       <--> (T,t)
	Session: (*,*,*)     <--> (T,t,Z)

If only one ICMP triplet can match, there is no room for "sibling" ICMP "connections" that share a "source" IPv4 identifier but not a "destination" IPv4 identifier like TCP and UDP do. The two pings will share both BIB entry and v4 endpoint address and therefore also share the session. The NAT64 is incapable of telling the two pings apart, and therefore cannot filter one of them.

There is no such thing as "Address-Dependent Filtering" on ICMP.

--------------------------------------
RFC6146 (draft-ietf-behave-v6v4-xlate-stateful-12)
--------------------------------------
Title               : Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers
Publication Date    : April 2011
Author(s)           : M. Bagnulo, P. Matthews, I. van Beijnum
Category            : PROPOSED STANDARD
Source              : Behavior Engineering for Hindrance Avoidance
Area                : Transport
Stream              : IETF
Verifying Party     : IESG