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

[marcelo bagnulo braun <[e-mail]>]

Reinaldo Penno escribió:
>
> 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.
>
>   
not sure what you mean by this.

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

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

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

> REQ-5: In NAT64 the ability to reap idle sessions early if the NAT can
> 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
> configure the idle-timeout is also missing.
>
>   
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.


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

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

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

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
> 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.
>
>   
in understand that both of these comments are not specific to the 
stateful document and should be addressed by the xlate draft.

Regards, marcelo

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