Subject: [BEHAVE] Review of xlate-stateful-07

From: Reinaldo Penno <[email-masked]>
Date: Thu, 31 Dec 2009 22:42:52 -0500

Hello,

Here it is my review of the above mentioned draft. The document contains the
comments, suggestions and others in marked style.

Thanks,

Reinaldo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 10 Jan 2010 20:10:04 +0100

Hi Reinaldo,

thanks for the review.

I include next my replies to each of the comments you made. 
Unfortunately, there is no handle or numbering for your comments, so, i 
will refer to them by the number fo comment, starting from the first one.

Comment 1: Added a Reference to ICE
Comment 2: Rephrased to
      The IPv4 addresses of IPv4 hosts are algorithmically translated to 
and from IPv6 addresses
      by using the algorithm defined in <xef 
target="I-D.ietf-behave-address-format"></xref> and
      a prefix assigned to the NAT64 for this specific purpose. The IPv6 
addresses of IPv6 hosts
      are translated to and from IPv4 addresses by installing mappings 
in the normal NAT manner.
Comment 3: I think that in general, more than one DNS servers are 
deployed for redundancy, so it is likely that more than one dns64 
capable server is also required.
Comment 4: I have added the follwiong sentence to provide apointer to a 
more detailed analysis
 A detailed analysis can be found
     in <xref target="I-D.penno-behave-64-analysis"></xref>.
Comment 5: I have rephrased as:
NAT64 implementations MAY use different data structures
            but they MUST store all the required information and the 
externally
               visible outcome MUST be the same as the one described in 
this document.</t>
Comment 6: The problem is that the fragmented packets may also contain 
UDP or TCP, so the subsections would not be per protocol, but for 
fragments of full packets and i am not convinced this would bring much 
clarity to the document.
Comment 7: based on the comments received, i have changed this to 2 
seconds. About your question, yes, the timer can be configured to 
whatever value imho
Comment 8: the idea is that both possible behaviour may be implemented.
Comment 9: I have rephrased this as:
               <t>The NAT64 sets (or resets) the timer in the Session Table
               Entry to maximum session lifetime. The maximum session 
lifetime MAY be configurable and
               the default SHOULD be at least 5 minutes.
               The maximum session lifetime MUST NOT be less than 2 min.
Comment 10: same text than the previous comment was included
Comment 11: i rahter use a new letter S', to avoid overloading the x'
Comment 12: same than before
Comment 13: This fall into the comment made earlier that the NAT64 may 
implement a different state machine as long as the external behaviour is 
the same
Comment 14: The lifetime in this state is set before getting into this 
state from the CLOSED state, where it reads: 
          The lifetime of the TCP session table entry is set to at least
          to 4 min (the transitory connection idle timeout as defined in
          [RFC5382]).
 The state of the session is moved to V6 SYN RCV.
Comment 15: Forwarded and translated, correct. The lifetime is not 
changed, since we are tracking the 3 way handshake and this is not part 
of it.
Comment 16: I don't understand this comment, could you expand?
Comment 17: rephrased as
If any packet other than the V6 FIN is received, ...
Comment 18: rephrased as:
If any packet other than the V4 FIN is received, ...
Comment 18: I don't understand the previous comment nor this one. Could 
you expand?
Comment 19: same reply than the previous similar comment
Comment 20: Again, i don't understnad the attack you are referring to. 
could you expand?

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 11 Jan 2010 14:30:43 -0500

Thanks Marcelo,

comments inline...

>                visible outcome MUST be the same as the one described in

'MAY' here gives the idea that anything different then proposed in the
document is 'optional' and what is proposed is the standard.

Any reason why not say...

"NAT64 implementations *are free to use* different data structures but they
MUST store all the required information and the externally visible outcome
MUST be the same as the one described in this document."

> implement a different state machine as long as the external behaviour is

Meaning you changed the text as in comment 5? The previous text referred in
comment 5 is specific to BIB and session tables. It does not say that TCP
state machine is mandatory or not.

I suggest then to add "TCP State machine" in the list, which would become:

o UDP Binding Information Base
o UDP Session Table
o TCP Binding Information Base
o TCP Session Table
o ICMP Query Binding Information Base
o ICMP Query Session Table
* TCP State Machine

> Comment 20: Again, i don't understnad the attack you are referring to.

This is from the previous email I sent you

...

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.

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 14 Jan 2010 01:02:47 -0500

Hi,

Are there any further clarifications needed? The answer to your questions
were within the email below.

Regards,

On 1/11/10 11:30 AM, "Reinaldo Penno" <[email-masked]> wrote:

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

---

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

> MUST be the same as the one described in this document."

I am unconvinced that this change is needed, but i don't see much of 
problem with doing it neither, and since it seems you feel strongly 
about it, let's go for it.
> comment 5 is specific to BIB and session tables.
no, i was referring to the text that refers to the break down into the 
steps, which is basically all the processing made by the nat64, which 
includes the TCP state amchine in particular.

>  It does not say that TCP

Right.

The problem with this is that as oposed to the nat44 case, it is not 
obvious in this case what is the "external" side
another interesting observation is that this seems to apply only to UDP 
and not for TCP (i.e. it is not mentioned in RFC 5382)

I think the solution may be to include some text int he security 
considerations (as i understand is your suggestion)

What about including the following text:

    <t>Another consideration related to NAT64 resource depletion refers 
to the
        preservation of binding state. Attackers may try to keep a 
binding state
        alive forever by sending periodic packets that refresh the state. In
        order to allow the NAT64 to defend against such attacks, the 
NAT64 MAY
        not extend the session entry lifetime for a specific entry upon 
the reception
        of packets for that entry through the external interface. As 
described in the
        Framework document  <xref 
target="I-D.ietf-behave-v6v4-framework"></xref>, the NAT64
        can be deployed in multiple scenarios, some of which the 
external side is the IPv6 one
        and some of which the external side is the IPv4 one. It is then 
important to properly
        set which is the external side of the NAT64 in each specific 
configuration.</t>

Regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Jan 2010 13:56:59 +1300

Marcelo,

On 2010-01-17 01:21, marcelo bagnulo braun wrote:

>    <t>Another consideration related to NAT64 resource depletion refers to the
>        preservation of binding state. Attackers may try to keep a binding state
>        order to allow the NAT64 to defend against such attacks, the NAT64 MAY
>        not extend the session entry lifetime for a specific entry upon the reception
>        of packets for that entry through the external interface. As described in the
>        Framework document  <xref target="I-D.ietf-behave-v6v4-framework"></xref>, the NAT64
>        can be deployed in multiple scenarios, some of which the external side is the IPv6 one
>        and some of which the external side is the IPv4 one. It is then important to properly
>        set which is the external side of the NAT64 in each specific configuration.</t>

This text shows exactly why "MAY NOT" may not be used according to RFC 2119 ;-)

I apologise for this defect in the English language, but I think you have to write
it differently:

 ..., the NAT64 MAY choose not to extend the session entry lifetime...

     Brian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 19 Jan 2010 14:45:29 +0100

fixed, thanks