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

[Michael Tuexen <[e-mail]>]

> On 15. Jul 2020, at 15:12, [e-mail] 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:[e-mail]]
>> Envoyé : lundi 13 juillet 2020 17:44
>> À : BOUCADAIR Mohamed TGI/OLN <[e-mail]>
>> Cc : [e-mail]
>> 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:[e-mail]]
>>>> Envoyé : mardi 7 avril 2020 14:10
>>>> À : BOUCADAIR Mohamed TGI/OLN
>>>> Cc : [e-mail]
>>>> Objet : Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-16.txt
>>>> 
>>>>> On 3. Apr 2020, at 18:42, [e-mail] wrote:
>>>>> 
>>>>> Hi Michael,
>>>>> 
>>>>> Please see inline.
>>>>> 
>>>>> Cheers,
>>>>> Med
>>>>> 
>>>>>> -----Message d'origine-----
>>>>>> De : tsvwg [mailto:[e-mail]] De la part de
>> Michael
>>>>>> Tuexen Envoyé : lundi 9 mars 2020 19:50 À : [e-mail]
>> Objet :
>>>>>> Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-16.txt
>>>>>> 
>>>>>>> On 9. Mar 2020, at 19:34, [e-mail] 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.
>