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

From: Michael Tuexen <[email-masked]>
Date: Mon, 13 Jul 2020 17:44:10 +0200

> 
> 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:[email-masked]]
>> Envoyé : mardi 7 avril 2020 14:10
>> À : BOUCADAIR Mohamed TGI/OLN
>> Cc : [email-masked]
>> Objet : Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-16.txt
>> 
>>> On 3. Apr 2020, at 18:42, [email-masked] wrote:
>>> 
>>> Hi Michael,
>>> 
>>> Please see inline.
>>> 
>>> Cheers,
>>> Med
>>> 
>>>> -----Message d'origine-----
>>>> De : tsvwg [mailto:[email-masked]] De la part de Michael
>>>> Tuexen
>>>> Envoyé : lundi 9 mars 2020 19:50
>>>> À : [email-masked]
>>>> Objet : Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-16.txt
>>>> 
>>>>> On 9. Mar 2020, at 19:34, [email-masked] 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,
>>>> 
>>>> this tries to
>>>> * address issues brought up by Maxim (see separate mail)
>>>> * add the YANG module provided by Mohamed
>>>> * address some of the issues reported bu Mohamed in a private mail
>>>> The .xml was also changed from v2 to v3.
>>>> 
>>>> The following suggestions from Mohamed were not integrated:
>>>> (a) replacing of NAT device to NAT function
>>>>   It is not clear to me what would be gained by this. Also other
>>>> documents
>>>>   (for example RFC 4787) also use NAT device.
>>> 
>>> [Med] The is basically to align with recent RFCs in this area, e.g.,
>>> 
>>> RFC6888 defines CGN as follows:
>>> 
>>>  Carrier-Grade NAT (CGN):  A NAT-based [RFC2663] logical function
>> used
>>>     to share the same IPv4 address among several subscribers.  A
>> CGN
>>>     is not managed by the subscribers.
>>> 
>>> The NAT is a function that is embedded in a device :-)
>> I was looking at
>> * https://tools.ietf.org/html/rfc2663
>> * https://tools.ietf.org/html/rfc4787
>> for example, which use NAT device.
>> 
>> Other documents just use NAT (in the sense of Network Address
>> Translator). I'll bring that up at the interim.
>>> 
>>> BTW a generic comment: the NAT document should not be specific to
>> NAT44, but should cover a variety of NAT flavors that are out there:
>> NAT64, DS-Lite, etc.
>> Concrete suggestions?
>>> 
>>> 
>>>> (b) replacing Private Address by Internal Address
>>>>   I would be fine with it (it would match Internal Port and
>> Internal
>>>> VTag).
>>>>   But it would break some relation we use for Private Address and
>>>> Public
>>>>   Address (the non-private IP address assigned to the NAT device).
>>> 
>>> [Med] Private address has a specific a meaning. For example, the
>> draft applies in the context of NAT64 as well, but there is no private
>> IPv4 address in the internal side of the NAT. The terminology should
>> be carefully chosen, IMO.
>>> 
>>>> (c) replacing Public Address by External Address
>>>>   This would leave us with no name for the host on the External
>>>> network
>>> 
>>> [Med] The external IP address is not necessary a public address;,
>> see for example the NAT in the CPE* .
>>> 
>>> 
>>>                                  :
>>>                                  |       Internet
>>>                  ............... | ...................
>>>                                  |       ISP network
>>>                  External pool:  |
>>>                  192.0.2.1/26    |
>>>                              ++------++  External realm
>>>                  ........... |  CGN   |...............
>>>                              ++------++  Internal realm
>>>                       10.0.0.1 |    |
>>>                                |    |
>>>                                |    |    ISP network
>>>                  ............. | .. | ................
>>>                                |    |  Customer premises
>>>                     10.0.0.100 |    | 10.0.0.101
>>>                        ++------++  ++------++
>>>                        |  CPE1  |  |  CPE2  |  etc.
>>>                        ++------++  ++------++
>>>                             |
>>>                             H (192.168.0.1)
>>> 
>>>>   the host behind the NAT wants to connect to and need to fit with
>>>>   Ext-Port and Ext-VTag.
>>>> 
>> What about using
>> 
>>  Internal Network    |         External Network
>>                      |
>>           Internal   |   External             Remote
>> +--------+ Address    |   Address  /--\/--\    Address +--------+
>> |  SCTP  |         +-----+        /        \           |  SCTP  |
>> |endpoint|=========| NAT |=======| Internet |==========|endpoint|
>> |    A   |         +-----+        \        /           |    B   |
>> +--------+ Internal   |            \--/\--/      Remote+--------+
>> Internal     Port    |                            Port    Remote
>>   VTag               |                                      VTag
>> 
>> instead of
>> 
>>  Internal Network    |         External Network
>>                      |
>>           Private    |   Public               External
>> +--------+ Address    |   Address  /--\/--\    Address +--------+
>> |  SCTP  |         +-----+        /        \           |  SCTP  |
>> |endpoint|=========| NAT |=======| Internet |==========|endpoint|
>> |    A   |         +-----+        \        /           |    B   |
>> +--------+ Internal   |            \--/\--/    External+--------+
>> Internal     Port    |                            Port  External
>>   VTag               |                                      VTag
>> 
>> That should address your comment and still provides a clear naming.
>>> 
>>> [Med] The
>> ???
>> 
>> Best regards
>> Michael
>>> 
>>>> I'm open to (a) if someone clarifies why NAT function is better
>> than
>>>> NAT device and explains why it wasn't used that way in, for
>> example,
>>>> RFC 4787.
>>>> 
>>>> I'm open to (b) and (c), I actually like (b), if someone can
>> suggest
>>>> than also a better name for the address/port/vtag the NATted host
>>>> is connecting to. We currently use Ext-Addr, Ext-Port, and Ext-VTag
>>>> for it.
>>>> 
>>>> However, these three issues are editorial and can be changed during
>>>> WGLC.
>>>> 
>>>> Best regards
>>>> Michael
>>>>> 
>>> 
>

---

From: <[email-masked]>
Date: Wed, 15 Jul 2020 13:12:00 +0000

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

> Envoyé : lundi 13 juillet 2020 17:44
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
> Cc : [email-masked]
> > "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
> >
> >>>> Tuexen Envoyé : lundi 9 mars 2020 19:50 À : [email-masked]
> Objet :
> >>>> Re: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-16.txt
> >>>>

_________________________________________________________________________________________________________________________

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.

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 26 Jul 2020 12:02:43 +0200

> On 15. Jul 2020, at 15:12, [email-masked] wrote:
> 
> Hi Michael, 
> 
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>

>   "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.
>   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

---

From: <[email-masked]>
Date: Mon, 27 Jul 2020 12:04:21 +0000

Hi Michael, 

Please see inline. 

Cheers,
Med

> Envoyé : dimanche 26 juillet 2020 12:03
> > 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.
> >
> the IP header forbids fragmentation, the NAT MUST send back a
> corresponding ICMP message to the internal host.
> 

[Med] The wording is IPv4-specifc: "When an SCTP packet ** has to be fragmented **".

You may consider my initial wording for IPv4 + add a new sentence to cover the IPv6 case.

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 27 Jul 2020 19:48:21 +0100

Hi Med,,

> On 27 Jul 2020, at 13:05, [email-masked] wrote:
> 
> Hi Michael, 
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
What do you think the IPv6 text should say?

Gorry

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 27 Jul 2020 22:12:52 +0200

> On 27. Jul 2020, at 14:04, [email-masked] wrote:
> 
> Hi Michael, 
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
Hmm. My view is that an IPv6 header always forbids fragmentation... So maybe
a bette workding helps:

<t>When an SCTP packet can not be sent by the NAT function due to MTU issues and
the IP header forbids fragmentation, the NAT MUST send back a
corresponding ICMP message to the internal host.

Is that acceptable?

Best regards
Michael

---

From: <[email-masked]>
Date: Tue, 28 Jul 2020 06:14:54 +0000

Hi Michael, 

That's better. 

I would: s/can not be sent/can not be forwarded.

I prefer if the "corresponding" message is called out in the text (that is, "Fragmentation needed and DF set" or PTB).

Thank you.

Cheers,
Med

> Envoyé : lundi 27 juillet 2020 22:13
> >> Envoyé : dimanche 26 juillet 2020 12:03 À : BOUCADAIR Mohamed
> TGI/OLN
> >> <[email-masked]> Cc : [email-masked] Objet : Re:
> >> [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-16.txt
> >>
> >>>  IP header forbids fragmentation a corresponding ICMP packet
> SHOULD
> >> be
> >>>  sent.
> >>>
> >>> NEW:
> Hmm. My view is that an IPv6 header always forbids fragmentation... So
> maybe a bette workding helps:
> 
> <t>When an SCTP packet can not be sent by the NAT function due to MTU
> issues and the IP header forbids fragmentation, the NAT MUST send back
> a corresponding ICMP message to the internal host.
> 
> Is that acceptable?
> 
> Best regards
> Michael
> >

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 28 Jul 2020 11:00:01 +0200

> On 28. Jul 2020, at 08:14, [email-masked] wrote:
> 
> Hi Michael, 
> 
> That's better. 
> 
OK.
> I prefer if the "corresponding" message is called out in the text (that is, "Fragmentation needed and DF set" or PTB).
Text no reads:
<t>When an SCTP packet can not be forwarded by the NAT function due to
MTU issues and the IP header forbids fragmentation, the NAT MUST send back a
"Fragmentation needed and DF set" ICMPv4 or PTB ICMPv6 message to the
internal host.

Pushed as rev-19.

Best regards
Michael