Subject: Re: [BEHAVE] General Comments on xlate-stateful-07

From: Reinaldo Penno <[email-masked]>
Date: Tue, 5 Jan 2010 08:43:57 -0500

Hi,

As a larger editorial note, I would suggest having a clear and concise
requirements section like previous behave documents. Also a summary of any
REQs that each normative section introduces.

I provided the requested information inline...

On 1/2/10 11:25 AM, "marcelo bagnulo braun" <[email-masked]> wrote:

> Hi,
> 
> thanks for the review.
> 
> one question about your comments
> 
> Reinaldo Penno escribió:
>> These are some general issues I feel need to be addresses before this draft
>> is published as a RFC:
>> 
>> 1 - Compliance with the previous BEHAVE RFCs seem not to have been examined
>> in detail. The draft states that:
>> 
>> " NAT64 as specified in this document is compliant with the
>>       recommendations for how NATs should handle UDP [RFC4787], TCP
>>       [RFC5382], and ICMP [RFC5508]..."
>> 
>> But reading NAT64 it seems we are not compliant with these documents. There
>> are differences in terms on how certain protocol are handled, MAYs vs.
>> SHOULDs vs. something new, etc.
>> 
>>   
> 
> do you have specfic points were the behave requirements are not
> complied? (i mean have you describe those in you detailed review you
> sent before?) If not, could you point exaxtly what behave requirements
> you think are not complied?

Sure, I included some comments in the detailed review and these are a subset
of other issues I collected while going through the spec in relation to
RFC5382. 

REQ-3: In NAT64 it is not clear the flexibility discussed in subsection a)
and b) are possible or required.

REQ-4: In NAT64 there is no SYN RCVD state in the proposed TCP state machine
and therefore you seem to be moving into ESTABLISHED state too early.

REQ-4: In the NAT64 spec it is not clear on what happens after the lifetime
expires in the case of simultaneous open. RFC5382 talks about sending ICMP
unless subsection a) applies

REQ-5: In NAT64 the ability to reap idle sessions early if the NAT can
determine if the endpoints are still alive is lost. Moreover, the ability to
configure the idle-timeout is also missing.

REQ-5: In the NAT64 spec the considerations on NAT throughput performance
due to holding session state for TCP RST and TIME_WAIT assassinations due to
holding session state are not discussed.

REQ-5: In the NAT64 spec the transition from ESTABLISHED to CLOSING (or FIN
WAIT-2) and FIN WAIT-1 is all bundled together so it is not clear when  and
who should start the TIME_WAIT timer (active vs. passive close).

REQ-6: In the NAT64 spec the considerations for ALGs seems to be missing.
Moreover needs text on how to reconcile the recommendation to have FTP ALG
enabled and the new specs.

There may be others after a more in-depth analysis. In general I think the
TCP state machine should be moved to a non-normative section or removed and
substituted by text covering only the really important aspects as in RFC5382
(which could be used almost verbatim). Otherwise I think more work is needed
in specifying it. 

A similar analysis of REQs found in other documents (including surrounding
text) should be done.

For example, in the case of RFC5508:

REQ-9: A clear statement such as the one found in REQ-9 seem to be missing
from the ICMP handling section.

REQ-10: Same as above. A concise section instead of many pages of discussion
helps furthering the understanding of the specification.

>> Therefore a proper analysis is needed of every REQ point. This would greatly
>> benefit the WG and make the document much clearer.
>> 
>>   
>> 2 - Implementation specific behavior
>> 
>> The draft accidently specifies implementation specific behavior under the
>> umbrella of ease of description, example, etc. Although existing
>> descriptions or examples are very nice, they might cause confusion (they
>> seem to already do given other emails on the list).
>> 
>> Therefore I would suggest anything that is not normative within the
>> normative section needs to be moved to an appendix or text stating beyond
>> doubt that something is just an example and developers are free as long as
>> external behavior is the same.
>> 
>>   
> same question than above, have you pointed out exactly what text you
> propose to move out of the normative descrtition?
> 

I included them in the detailed review: Data structures in general, TCP
state machine, etc

>> 3 - Security
>> 
>> The security section is very light at this point. There are many documents
>> pertaining to NAT security in general that should be referenced or more text
>> needs to be there.
>> 
>>   
> Do you have any concrete text or issues that should be covered in the
> security section?

Some of comments pertaining to the analysis of REQs early in this email also
have a security component to it and I included others in my detailed review:
TCP RST, holding state, timers, etc.

Moreover, the way the UDP and TCP handling is specified basically disallows
building a more secure NAT implementation on top of it (more on it below).
And this goes back to first point in relation to differences between
previous behave documents and this one.

For example, important security considerations related to inbound packets
resetting the timers of sessions (RFC4787) are missing.

"  This document recommends that the timers for mapping be refreshed on
   outgoing packets (see REQ-6) and does not make recommendations about
   whether or not inbound packets should update the timers.  If inbound
   packets update the timers, an external attacker can keep the mapping
   alive forever and attack future devices that may end up with the same
   internal address. "

The NAT64 spec allows inbound packets by default to reset the timer in
normal UDP packet handling and also in the case of TCP, TCP RST, etc. This
is a important practical considerations that secure NAT implementations take
into account.

> 
> Regards, marcelo
> 
>> Misc Item:
>> 
>> 4 - The use X', T, t and others... I do not know the history behind this
>> nomenclature but I would suggest something more intuitive such as S-IPv6,
>> D-IPv6, etc. 

How about this one? Can actual addresses be used in section 1.2.2? Or some
other nomenclature?

Thanks,

Reinaldo

>> Thanks,
>> Reinaldo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 16 Jan 2010 13:50:19 +0100

> and b) are possible or required.
not sure what you mean by this.

The current version of the draft explicty specifies how to perform 
endpoint independent and address dependent filtering

> and therefore you seem to be moving into ESTABLISHED state too early.

not sure how req 4 requires a SYN RCVD state
there is an ongoing disucssion on the ml about whether the NAT64 shoudl 
send an ICMP error at all, and there are some proponents that they it 
shouldn't.
> unless subsection a) applies
this is being under disucssion right now
the problem is that in order to do so, the nat64 need to store the v4 
syn during the 6 secs, an some people seem to have a problem with that

but as i said, this is being disucssed. If you have an opinion, please 
state it

> determine if the endpoints are still alive is lost.

this is also being discussed in the ml right now, based on Bryan's 
review abouth whether the NAT64 shoudl send keepalives to detect whether 
the TCP connection is alive or not. Again, feel free to state your 
opinion so we can reach consensus on this issue

>  Moreover, the ability to
right,

i have added the follwoing text in all the occureences of the the 
setting of the TCP session entry lifetite

                    The lifetime of the TCP session table entry is set 
to at least to the maximum session lifetime. The value for the maximum
                    session lifetime MAY be configurable but it MUST not 
be less than TCP_EST (the
                    established connection idle timeout as defined in 
<xref target="RFC5382"></xref>). The default value for the maximum 
session lifetime
                    SHOULD be set to TCP_EST.

> holding session state are not discussed.

REQ5 leaves these aspects open and so the nat64 specification. Do you 
have any particualr text that you would like to cinlcude in the nat64 
spec w.r.t. this?
> who should start the TIME_WAIT timer (active vs. passive close).

the nat64 would not start a time wait. the conclusion form previous 
discussions was to have a long (4 min) lifetime of the v4 fin + v6 fin 
rcv state, so we can forward all remaining packets and then drop the 
session. this shoudl accomodate for all reaining packets afaiu.
> enabled and the new specs.

NAT64 does not specifies any alg, so they are disabled by default, as 
reccomended

The ftp64 case was debated and the conclusion was that it should be done 
in a separated document, which is now the case, so any issues about ftp 
alg shoudl be addressed by that document.
> There may be others after a more in-depth analysis.
please feel free to bring them up and we will address them

>  In general I think the
in understand that both of these comments are not specific to the 
stateful document and should be addressed by the xlate draft.

Regards, marcelo

---

From: Reinaldo Penno <[email-masked]>
Date: Sat, 16 Jan 2010 16:11:33 -0500

Hello,

Comment inline...

>                     SHOULD be set to TCP_EST.

The whole purpose to have it configurable was to be able to configure it to
be _less_ than TCP_EST.

The text above does not allow it to be set to less than TCP_EST. I suggest

"The lifetime of the TCP session table entry is set
to at least to the maximum session lifetime. The value for the maximum
session lifetime MAY be configurable  The default value for the maximum
session lifetime SHOULD be set to TCP_EST."

Tuning TCP idle timeout is widely supported and used.

> have any particualr text that you would like to cinlcude in the nat64

The exact same text (or a reference to it) found in RFC5382.

Regards,

Reinaldo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 16 Jan 2010 23:34:12 +0100

> The whole purpose to have it configurable was to be able to configure it to
no, that would break REQ5 of RFC5382 that reads:

   REQ-5:  If a NAT cannot determine whether the endpoints of a TCP
      connection are active, it MAY abandon the session if it has been
      idle for some time.  In such cases, the value of the "established
      connection idle-timeout" MUST NOT be less than 2 hours 4 minutes.
      The value of the "transitory connection idle-timeout" MUST NOT be
      less than 4 minutes.
      a) The value of the NAT idle-timeouts MAY be configurable.

> Tuning TCP idle timeout is widely supported and used.

right, but the minimum value MOST NOT be less than 2 hours and 4 min
> The exact same text (or a reference to it) found in RFC5382.
could you point out what exact same text you are referring to?

Regards, marcelo

---

From: Reinaldo Penno <[email-masked]>
Date: Sat, 16 Jan 2010 20:54:29 -0500

It clearly says in a)  that the idle timeout MAY be configurable. How  
will my proposed text break 5382?

It also says that only in case the NAT cannot determine if endpoints  
are alive.

Why we just then just copy REQ5 verbatim?

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 17 Jan 2010 13:07:06 +0100

> will my proposed text break 5382?

THere are two conditions:
MUST be more than 2 hours and 4 min
MAY be configurable.

So, my reading of the conditions is an AND of the two conditions, not an 
OR.
Maybe someone else should comment whether they think it is an AND or an 
OR....?

If it is an AND, then you can configire the timer, but needs to be 
higher than 2 hours and 4 min, in any case, as it is currently stated in 
the draft

It is is an OR, it is as you say, but at this point i don't interpret 
the text as a OR
> It also says that only in case the NAT cannot determine if endpoints  

right, we are having a disucssion whether the nat64 should send 
keepalives to do this, do you think it should or not?

> Why we just then just copy REQ5 verbatim?
on the light of this discussion, it seems that the current wording is 
unclear, since you and me have different readings of it

Regards, marcelo

---

From: Reinaldo Penno <[email-masked]>
Date: Sun, 17 Jan 2010 18:11:52 -0500

What I mean is that the sentence starts of with "In such cases...".  These
'cases' are those when the NAT cannot determine whether the endpoints of a
TCP connection are active, as written.

Therefore this first paragraph only applies to this condition. If you can
actually determine if the NAT endpoints are alive, you do not need to follow
this paragraph. 

My opinion is that we should just follow REQ-5 as stated. This is would take
care of Bryan's proposal as well.

---

From: Lars Eggert <[email-masked]>
Date: Mon, 18 Jan 2010 12:30:34 +0200

> Maybe someone else should comment whether they think it is an AND or an 

I think the intent was for an AND (i.e., they can be configured to be longer.)

Lars

---

From: Lars Eggert <[email-masked]>
Date: Mon, 18 Jan 2010 12:32:39 +0200

Hi,

> TCP connection are active, as written.

right. I believe the thinking was that if you can detect whether the session is alive, you wouldn't time it out if it was, and you would of course time it out if it wasn't.

If you cannot determine this, then the default applies (and can't be shorter than 2 hours.)

Lars

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 19 Jan 2010 04:36:55 -0500

That is fine. It seems we agree with the first part of the the
interpretation, so let's take a step further.

Let's suppose you configure the idle timeout to be 30 minutes, send N
keep-alive TCP packets, receive no response, and proceed to delete the NAT
mapping. Is this behavior compliant of REQ-5? And how about NAT64?

Thanks,

Reinaldo

On 1/18/10 2:32 AM, "Lars Eggert" <[email-masked]> wrote:

> right. I believe the thinking was that if you can detect whether the session
> is alive, you wouldn't time it out if it was, and you would of course time it
> out if it wasn't.
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 20 Jan 2010 13:27:16 +0100

> If you cannot determine this, then the default applies (and can't be shorter than 2 hours.)
Right

My proposed way forward is:

- If the NAT64 sees a FIN exchange, then it deletes the binding (after 4 
min) (i.e. we are using the capability of terminating the binding 
earlier than the 2 hr 4 min timeout)
- If the NAT64 sees a RST and no packets for 4 min, then it terminates 
the binding (again we are using the capability of termianting the 
binding earlier)
- if the nat64 times out after 2 hours, it sends a probe packet and if 
no packet is seen after that, it terminates the session after 4 min (in 
this case, we do use the 2 hours and 4 min timeout)

would that sounds ok to you?

Regards, marcelo

> ------------------------------------------------------------------------
>
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 21 Jan 2010 01:16:30 -0500

Hello,

Thanks for the proposal, comments inline...

> the binding (again we are using the capability of termianting the

As opposed to what behavior? Wasn't it always like this? I guess I'm puzzled
by the " again we are using the capability of terminating the binding
earlier...". 

> would that sounds ok to you?

Yes. I would suggest that the number of probe packets needs to be
configurable and also whether you send to both endpoints or only the
initiating endpoint.

Having said that, I'm still looking for the answer to my previous question.

" Let's suppose you configure the idle timeout to be 30 minutes, send N
keep-alive TCP packets, receive no response, and proceed to delete the NAT
mapping. Is this behavior compliant of REQ-5? And how about NAT64?"

If this is compliant with REQ-5 I'm looking the find out if there is a way
for NAT64 to accept this type of behavior because, like in NAT44, in my
opinion it would reflect the eventual use in deployments.

Thanks,

Reinaldo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 21 Jan 2010 12:05:29 +0100

> by the " again we are using the capability of terminating the binding

again, because we are using with the FINs and with the RST
> configurable and also whether you send to both endpoints or only the
My proposal is that the nat64 can generate one or two probes (two being 
one to each endpoint)

the problem with these probe packets is that each of them generate 2 
packets (one from each endpoint)
This means that if we send 2 probes,it will result in 4 packets from the 
endpoints. If we go for 4 probes it will generate 8 packets, which i 
deem excesive
> opinion it would reflect the eventual use in deployments.
as i mentioned earlier, i think that a binding can be finished earlier 
than 2 hrs if there is a FIN exchange or if there is a RST. In the 
absence of these, i am not sure we should go lower than the 2 hour timer 
(this is how i interpret the intention of the req 5)

I understand you have a different opinion and you would prefer to have 
the nat sending probes earlier.

I would like to hear other people opinion on this at this point.

Regards, marcelo

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 21 Jan 2010 14:30:18 -0500

I believe REQ-5, item a), came originally from

http://tools.ietf.org/html/draft-hoffman-behave-tcp-04

The justification in the text (which was not incorporated in RFC5382) was

"      a) Configuration helps troubleshoot and accommodate specific
         applications."

Thanks Reinaldo.

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 21 Jan 2010 14:31:40 -0500

Hi,

I trimmed the thread a bit...

> endpoints. If we go for 4 probes it will generate 8 packets, which i

This looks fine. If only one of the endpoints reply, should we still reap
the session? Anyway, a few considerations from a previous behave meeting:

"
TCP Keep-alive

*Upon Session Timer expiry, NAT SHOULD enter a "probe" state and send TCP
keep-alive packets to internal endpoint.

*Upon receiving ACK or data traffic, NAT should reset Session Timer and
remain in ACTIVE state.

*Upon receiving RST, NAT should forward the RST to External Server, enter
CLOSING state and start Close Timer.

*Upon not receiving any response after a few retries, NAT should send RST to
both parties, enter CLOSING state and start Close Timer.
"

FWIW, I believe in the early versions of RFC5382 there was a discussion
around probe packets and only the initiating side would have a saying on
whether the binding would be kept alive in the case of probes packets. The
reason was security. Optionally both could be implemented.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 21 Jan 2010 23:26:35 +0100

Reinaldo Penno escribió:
> the session? 
mmm, the answer to this one is tricky

The current text allows to send a single probe to one of the endpoints. 
If this endpoint does not reply, then the nat64 would reap the state.
However, if this one replies, but the other endpoint doesn't, then the 
nat64 would keep th state. I think this actually is aligned with the 
text you include below.

I mean, the proposed text for nat64 allows to send a probe to only one 
of the end points. Since the internal/external sides are not clearly 
defined in the nat64 case compared to the nat44 case, then the current 
text allows for the nat64 to only probe the internal side (defined by 
the admin).

So, the current text supports that the nat64 only pobes the internal 
side and if there is no answer, the state is deleted. Woudl that work 
for you?

Regards, marcelo

> Anyway, a few considerations from a previous behave meeting:
>
> "
> TCP Keep-alive
>

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 21 Jan 2010 17:33:26 -0500

Yes, that is fine.

Thanks,

---

From: WashamFan <[email-masked]>
Date: Fri, 22 Jan 2010 10:30:01 +0800

Hi,

>  this case, we do use the 2 hours and 4 min timeout)

In this case, probing is a means to detect TCP session health just as
FIN and RST, so personally, I don't think the last bullet should put
2h 4m restriction according to REQ5 RFC5382.

Thanks,
washam

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 22 Jan 2010 04:04:43 +0100

> 2h 4m restriction according to REQ5 RFC5382.

probably i didn't explain myself clearly.... In this case, if the 
endpoint replies to the probe, the binding not deleted.

Regards, marcelo

---

From: WashamFan <[email-masked]>
Date: Fri, 22 Jan 2010 11:31:40 +0800

Hi Marcelo,
  
>  >>  - if the nat64 times out after 2 hours, it sends a probe packet 
> and 
>  >> if 
>  >>  no packet is seen after that, it terminates the session after 4 
> min 
>  >> (in 

Yes, and if there is no reply after maximum probe retries, the binding
deleted. That is how probe works to detect TCP session status.

My point is, NAT can determine whether the endpoints of a TCP
connection are active via probe means as well as FIN, RST means,
so REQ-5 RFC5382 should not apply to the case where probe is used.

In other words, NAT MUST delete binding if no flow detected after
2h 4m timeout without probing.

Thanks,
washam

---

From: Lars Eggert <[email-masked]>
Date: Fri, 22 Jan 2010 11:09:40 +0200

Hi,

On 2010-1-22, at 5:10, Saikat Guha wrote:
> On Mon, Jan 18, 2010 at 11:30 AM, Lars Eggert <[email-masked]> wrote:
> A quick clarification ... the intent of RFC 5382 REQ-5a) "MAY be
> configurable" was to allow for shorter than 2h 4m idle timeout when
> under attack (even for NATs that cannot actively probe for liveness) .
> 
>   """Security considerations for REQ-5:  This document recommends that a
>      NAT that passively monitors TCP state keep idle sessions alive for
>      at least 2 hours 4 minutes or 4 minutes depending on the state of
>      the connection.  If a NAT is under attack, it may attempt to
>      actively determine the liveliness of a TCP connection or let the
>      NAT administrator configure more conservative timeouts."""

I disagree that allowing configuration was for attack prevention. It was to allow for longer, more conservative, defaults.

As the security considerations clearly say, *if the NAT is under attack* it may take means to protect itself, e.g. by terminating sessions for which a liveness check fails. Other ways of shedding load are fair game, too. If the NAT is in danger to go down from overload, all sessions would break in any event, so killing off sessions to stay up seems like a reasonable tradeoff *under attack*.

I don't actually understand the bit about "more conservative timeouts" because "more conservative" means "longer" and not "shorter".

Lars

---

From: Saikat Guha <[email-masked]>
Date: Fri, 22 Jan 2010 04:10:25 +0100

-- 
Saikat