Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-16.txt

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Sun, 26 July 2020 10:02 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E433A0D41 for <tsvwg@ietfa.amsl.com>; Sun, 26 Jul 2020 03:02:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.621
X-Spam-Level:
X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.267, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 049uE31T4VAG for <tsvwg@ietfa.amsl.com>; Sun, 26 Jul 2020 03:02:49 -0700 (PDT)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CADC3A0D40 for <tsvwg@ietf.org>; Sun, 26 Jul 2020 03:02:48 -0700 (PDT)
Received: from [IPv6:2a02:8109:1140:c3d:789f:e52a:4f1d:f41d] (unknown [IPv6:2a02:8109:1140:c3d:789f:e52a:4f1d:f41d]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id B6AE1721E282D; Sun, 26 Jul 2020 12:02:44 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <9842_1594818722_5F0F00A2_9842_128_4_787AE7BB302AE849A7480A190F8B9330314F980A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Sun, 26 Jul 2020 12:02:43 +0200
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F03E124F-E4DB-4D68-96F5-3EDB48C31883@lurchi.franken.de>
References: <158377886936.5575.9623052267692928298@ietfa.amsl.com> <4C917C1B-74C0-4E5E-B26C-3CD6A0B2544C@lurchi.franken.de> <787AE7BB302AE849A7480A190F8B93303148DE10@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <F3B1520B-593F-426A-8AC4-9B2371A82B37@lurchi.franken.de> <787AE7BB302AE849A7480A190F8B9330314902D1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <FC1544B5-87B1-4A46-BEA7-00541206883A@lurchi.franken.de> <9842_1594818722_5F0F00A2_9842_128_4_787AE7BB302AE849A7480A190F8B9330314F980A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
To: mohamed.boucadair@orange.com
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/BVXUerb2NT6ILEifZIsYq5cPu8A>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-16.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Jul 2020 10:02:52 -0000


> On 15. Jul 2020, at 15:12, mohamed.boucadair@orange.com wrote:
> 
> Hi Michael, 
> 
> Thank you for these changes and also for the NEW text in the fragmentation section. 
> 
> I skimmed over the new version. This looks good overall but I still have some comments on fragmentation: 
> 
> * By "NAT function MUST support IP reassembly", do you mean "NAT function MUST reassemble"? Or do you have in mind a configuration knob to enable/disable the behaviour? 
You are right. This is not needed. What is needed it:

<t>Therefore, a NAT function MUST be able to handle IP-level fragmented
SCTP packets. The fragments may arrive in any order.</t>

> * I still don't see why it is the responsibility of the NAT to reassemble packets. Of course, an implementation can decide to do so. 
> * I prefer the behaviour in RFC6146 that says the following: 
> 
> ==
>   If the incoming IP packet contains a fragment, then more processing
>   may be needed.  This specification leaves open the exact details of
>   how a NAT64 handles incoming IP packets containing fragments, and
>   simply requires that the external behavior of the NAT64 be compliant
>   with the following conditions:
> 
>      The NAT64 MUST handle fragments.  In particular, NAT64 MUST handle
>      fragments arriving out of order, conditional on the following:
> 
>      *  The NAT64 MUST limit the amount of resources devoted to the
>         storage of fragmented packets in order to protect from DoS
>         attacks.
> 
>      *  As long as the NAT64 has available resources, the NAT64 MUST
>         allow the fragments to arrive over a time interval.  The time
>         interval SHOULD be configurable and the default value MUST be
>         of at least FRAGMENT_MIN
> 
>      *  The NAT64 MAY require that the UDP, TCP, or ICMP header be
>         completely contained within the fragment that contains fragment
>         offset equal to zero.
> 
>      For incoming packets carrying TCP or UDP fragments with a non-zero
>      checksum, NAT64 MAY elect to queue the fragments as they arrive
>      and translate all fragments at the same time.  In this case, the
>      incoming tuple is determined as documented above to the un-
>      fragmented packets.  Alternatively, a NAT64 MAY translate the
>      fragments as they arrive, by storing information that allows it to
>      compute the 5-tuple for fragments other than the first.  In the
>      latter case, subsequent fragments may arrive before the first, and
>      the rules (in the bulleted list above) about how the NAT64 handles
>      (out-of-order) fragments apply.
> 
>      For incoming IPv4 packets carrying UDP packets with a zero
>      checksum, if the NAT64 has enough resources, the NAT64 MUST
>      reassemble the packets and MUST calculate the checksum.  If the
>      NAT64 does not have enough resources, then it MUST silently
>      discard the packets.  The handling of fragmented and un-fragmented
>      UDP packets with a zero checksum as specified above deviates from
>      that specified in [RFC6145].
> ==
> 
> In any case, I'm afraid you will need to add details such as: amount of time/resources a NAT can wait for out of order fragments. You may reuse some of the text from RFC 6146, including the default frag timeout.
> 
> * Consider this change to align with REQ-13 of RFC4787:
> 
> OLD:
>   When an SCTP packet has to be fragmented by the NAT function and the
>   IP header forbids fragmentation a corresponding ICMP packet SHOULD be
>   sent.
> 
> NEW:
>   When an SCTP packet has to be fragmented by the NAT function and the
>   IP header forbids fragmentation, the NAT MUST send back an ICMP message 
>   "Fragmentation needed and DF set" to the internal host.
Changed to
<t>When an SCTP packet has to be fragmented by the NAT function and
the IP header forbids fragmentation, the NAT MUST send back a corresponding
ICMP message to the internal host.

since it covers IPv4 and IPv6.
> 
> * Consider aligning with RFC7857#section-10:
> 
>   A NAT SHOULD handle the Identification field of translated
>   IP packets as specified in Section 5.3.1 of [RFC6864].
I would like to cover non-SCTP stuff as minimal as possible. So not adding
this right now.
> 
> * Cite RFC4963 in the security section.
OK. I added:
<t>For IP-level fragmentation and reassembly related issues see
<xref target="RFC4963" />.

Best regards
Michael
> 
> Hope this helps. 
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]
>> Envoyé : lundi 13 juillet 2020 17:44
>> À : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>
>> Cc : tsvwg@ietf.org
>> Objet : Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-16.txt
>> 
>>> 
>>> Hi Michael,
>>> 
>>> Your new "Basic network setup" is better. Thanks.
>> OK, using it.
>>> 
>>> I would add a note saying the following:
>>> 
>>> "The NAT in the document refers to NAPT described in Section 2.2
>> of [RFC3022], NAT64 [RFC6146], or DS-Lite [RFC6333]."
>> Added.
>> 
>> Best regards
>> Michael
>>> 
>>> Cheers,
>>> Med
>>> 
>>>> -----Message d'origine-----
>>>> De : Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]
>>>> Envoyé : mardi 7 avril 2020 14:10
>>>> À : BOUCADAIR Mohamed TGI/OLN
>>>> Cc : tsvwg@ietf.org
>>>> Objet : Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-16.txt
>>>> 
>>>>> On 3. Apr 2020, at 18:42, mohamed.boucadair@orange.com wrote:
>>>>> 
>>>>> Hi Michael,
>>>>> 
>>>>> Please see inline.
>>>>> 
>>>>> Cheers,
>>>>> Med
>>>>> 
>>>>>> -----Message d'origine-----
>>>>>> De : tsvwg [mailto:tsvwg-bounces@ietf.org] De la part de
>> Michael
>>>>>> Tuexen Envoyé : lundi 9 mars 2020 19:50 À : tsvwg@ietf.org
>> Objet :
>>>>>> Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-16.txt
>>>>>> 
>>>>>>> On 9. Mar 2020, at 19:34, internet-drafts@ietf.org wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> A New Internet-Draft is available from the on-line Internet-
>> Drafts
>>>>>> directories.
>>>>>>> This draft is a work item of the Transport Area Working
>> Group WG
>>>> of
>>>>>> the IETF.
>>>>>>> 
>>>>>>>     Title           : Stream Control Transmission Protocol
>>>> (SCTP)
>>>>>> Network Address Translation Support
>>>>>>>     Authors         : Randall R. Stewart
>>>>>>>                       Michael Tuexen
>>>>>>>                       Irene Ruengeler
>>>>>>> 	Filename        : draft-ietf-tsvwg-natsupp-16.txt
>>>>>>> 	Pages           : 47
>>>>>>> 	Date            : 2020-03-09
>>>>>> Dear all,
> 
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>