Subject: [tsvwg] Review of draft-ietf-tsvwg-behave-requirements-update-04

From: Brandon Williams <[email-masked]>
Date: Mon, 2 Nov 2015 23:42:08 -0500

I reviewed this draft today. I've got two questions about the substance 
of the draft and a few suggestions for corrections/clarifications.

First, the two substance questions.

S4
It’s unclear to me why the default APP behavior on port exhaustion 
should be to drop new connections, rather than using a different 
address. A default setting that allows new connections to get through 
seems better. If the current SHOULD remains in place, I think it needs a 
clearer justification that explains the impact on NAT unfriendly 
applications in the event of an address change, since that impact would 
have to be quite significant to outweigh the negative impact of dropping 
new connections.

S7
It’s unclear why EIF should be protocol _independent_ but EIM should be 
protocol _dependent_. The doc appears to be recommending conflicting 
behaviors for outbound packet handling and inbound packet handling. Why 
isn’t the recommendation for EIF and EIM the same (either both protocol 
dependent or both protocol independent)?

And now some corrections and/or requests for clarification.

S1
    But with widespread deployment and
    evolution of Network Address Translation (NAT) more development and
    operational experience was acquired some areas of the original
    documents need further clarification or updates.

This sentence is difficult to parse. I suggest:

    Operational experience gained through widespread deployment and
    evolution of Network Address Translation (NAT) indicates that some
    areas of the original documents need further clarification or
    updates.

S2
The diagram is difficult to read due to spanning pages. If there’s a way 
to add a page break in order to ensure that the whole diagram appears on 
one page, that would be helpful.

Also regarding the diagram, shouldn’t there be some sort of timeout 
based transition from each of the two FIN RCV states? And which timeout 
should it be (EST or TRANS)? I’ve got the same comment for the INIT 
state. Section 2.1 goes on to discuss these timeouts. I see that these 
timeouts were also missing from the RFC6146 diagram, so maybe this was 
intentional and just a comment to let the reader know that the diagram 
is simplified would be enough.

S2.1
     To accommodate deployments that consider a partially open timeout
     of 4 minutes as being excessive from a security standpoint, a NAT
     MAY allow to configure the timeout to be less than 4 minutes.
     Still, this specification recommends the default "transitory
     connection idle-timeout" minimum value to be set to 4 minutes.

The wording here is a little difficult to parse, and it’s unclear 
whether the second sentence is referring to only the open timeout or to 
all transitory timeouts (I think it’s the later). I suggest:

     ... a NAT MAY allow the configured timeout to be less than 4
     minutes. However, a minimum default “transitory connection
     idle-timeout” of 4 minutes is RECOMMENDED.

S2.2
     ... removing any state associate with it ...

s/associate/associated/

S2.2
       Admittedly, the NAT has to verify whether received TCP RST packets
       belong to a connection.  These verification checks are required to
       avoid off-path attacks.

It’s unclear what verification checks are being called for here. Do you 
mean anything more than validating the full connection 4-tuple? It might 
be good to clarify.

S11
   Section 3.1 of [RFC5508] precises that ICMP Query Mappings are to be
   maintained by a NAT.

s/precises/specifies/

Please let me know if any of the above is unclear.

--Brandon

---

From: <[email-masked]>
Date: Tue, 3 Nov 2015 15:59:42 +0000

Hi Brandon, 

Thank you for the review. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Brandon Williams [mailto:[email-masked]]
> Envoyé : mardi 3 novembre 2015 05:42
> À : [email-masked]; [email-masked]
> Objet : Review of draft-ietf-tsvwg-behave-requirements-update-04
> 

[Med] The motivation is the same as in RFC4787: avoid breaking some applications (e.g., RTP/RTCP). This specification allows to relax that behavior but only as a configurable parameter. As currently written, the text does not break RFC4784 but allows to relax that behavior to accommodate deployment contexts. 

> dependent or both protocol independent)?

[Med] These two recommendations seem to be conflicting because they are motivated by distinct objectives. The rationale for having EIM protocol-dependent is to optimize the usage of the available port space by reusing the same port number assigned for a packet over transport X issued by an internal host A for another packet issued from a distinct internal host B but over transport Y. The EIF behavior is more friendly with applications that multiplex the connections over the same IP address/port. The proposed EIF behavior allows for those incoming connections to pass the filtering, but in order to be forwarded to the internal host, a mapping bound to the transport protocol should be present in the binding table or EIM is set to protocol-independent.

>     areas of the original documents need further clarification or

[Med] Fixed. Thank you.

> one page, that would be helpful.

[Med] Fixed. 

> is simplified would be enough.

[Med] Yes, the intent is to provide a similar simplified state machine as in RFC6146 which states the following: "The figure presents a simplified version of the state machine;". I updated changed the title of the diagram to :"Simplified version of the state machine".

>      idle-timeout” of 4 minutes is RECOMMENDED.

[Med] Works for me.

>      ... removing any state associate with it ...

[Med] Thank you for catching this. Fixed.

> mean anything more than validating the full connection 4-tuple? It might

[Med] What is meant is verifying the 5-tuple (including the protocol). Changed to: "This verification check is required to avoid off-path attacks."

>    Section 3.1 of [RFC5508] precises that ICMP Query Mappings are to be

[Med] Fixed.

> Please let me know if any of the above is unclear.
[Med] Your review is appreciated! Thank you.

---

From: Brandon Williams <[email-masked]>
Date: Wed, 4 Nov 2015 03:23:39 -0500

Hi Med,

Re: S4
I don't agree that the justification for the APP behavior described in 
RFC4787 is also a justification for dropping packets in the presence of 
NAT port exhaustion. Not all applications require the APP behavior, and 
if a NAT drops packets (fails connections) in a port exhaustion scenario 
on a single address when ports are available on other addresses, it may 
unnecessarily break applications that don't require this behavior. In 
other words, this could degrade better behaved apps in a case where the 
badly behaved app is likely to break anyway. This is why I think the doc 
needs either a different recommendation or a stronger justification for 
the current recommendation.

Re: S7
OK, so the idea is that filtering and forwarding are separate stages in 
the packet handling, and the recommendation is loose filtering in order 
to handle the possibility that the mapping is configured to be protocol 
independent. I don't find that justification particularly compelling. If 
both are configured with the recommended defaults, the packet is allowed 
through the filter stage only to be dropped when you fail looking up the 
mapping. It seems to be describing a pair of default settings that might 
unnecessarily increase aggregate load. Here too, I think that the doc 
needs either a different recommendation or a stronger justification for 
the current recommendation, though I don't feel as strongly about this 
one as the previous one.

--Brandon

-- 
Brandon Williams; Chief Architect
Cloud Networking; Akamai Technologies Inc.

---

From: <[email-masked]>
Date: Wed, 4 Nov 2015 09:59:37 +0000

Hi Brandon,

Please see inline. 

Cheers,
Med

> Envoyé : mercredi 4 novembre 2015 09:24
> À : BOUCADAIR Mohamed IMT/OLN; [email-masked]; draft-ietf-tsvwg-behave-
> [email-masked]
> Objet : Re: Review of draft-ietf-tsvwg-behave-requirements-update-04
> 
> Hi Med,
> 
> Re: S4

[Med] I do agree that not all applications require the APP behavior, but some may break if distinct IP addresses are assigned by the NAT. The current text in S4 does not change the recommendation in RFC4787. All what it does is to clarify the unspecified behavior in that RFC: i.e., the behavior when the external IP address runs out of ports. We had indeed two options: assign a port on another external IP address, or reject the new connection. We went for the second approach because it is close to the behavior in RFC6888 (that is specific to the CGN case): 

" a CGN must use the same external IP
      address mapping for all sessions associated with the same internal
      IP address, be they TCP, UDP, ICMP, something else, or a mix of
      different protocols."

Also, the motivation is that the NAT does not know whether the extra connections require the external IP address to be constant. In such case, assigning a port on another external IP address may consume a port (i.e., inefficient use of resources) with no guarantee that the connection will be accepted by the remote peer. 

In theory, the downside of this approach is the connections that do not require the same external IP address may be rejected by the NAT. But for the particular case of the CGN, requiring the same IP address to be assigned didn't led to extra session failures but has educated operators to be more careful when tweaking the port quota to be assigned to internal hosts and, consequently, implementations are designed to adequately set how many internal hosts can share a same external IP address. 

> the current recommendation, though I don't feel as strongly about this

[Med] I thought about this further yesterday after my reply to your first message. I do tend to agree it is simple to align the settings of both EIM and EIF. This will be fixed in the next iteration.  

> > [Med] The motivation is the same as in RFC4787: avoid breaking some
> applications (e.g., RTP/RTCP). This specification allows to relax that
> behavior but only as a configurable parameter. As currently written, the
> text does not break RFC4784 but allows to relax that behavior to
> accommodate deployment contexts.
> >
> >> S7
> > [Med] These two recommendations seem to be conflicting because they are
> motivated by distinct objectives. The rationale for having EIM protocol-
> dependent is to optimize the usage of the available port space by reusing
> the same port number assigned for a packet over transport X issued by an
> internal host A for another packet issued from a distinct internal host B
> but over transport Y. The EIF behavior is more friendly with applications
> that multiplex the connections over the same IP address/port. The proposed
> EIF behavior allows for those incoming connections to pass the filtering,
> but in order to be forwarded to the internal host, a mapping bound to the
> transport protocol should be present in the binding table or EIM is set to
> protocol-independent.
> >
> >>
> > [Med] Yes, the intent is to provide a similar simplified state machine
> as in RFC6146 which states the following: "The figure presents a
> simplified version of the state machine;". I updated changed the title of
> the diagram to :"Simplified version of the state machine".
> >
> >>
> >>
> >> S2.1
> > [Med] What is meant is verifying the 5-tuple (including the protocol).
> Changed to: "This verification check is required to avoid off-path
> attacks."
> >
> >>
> >> S11