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

[[e-mail]]

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? 
* 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.

* 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].

* Cite RFC4963 in the security section.

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.