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

[Reinaldo Penno <[e-mail]>]

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" <[e-mail]> 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
>> 
>> 
>> 
>> 
>> 
>> 
>>   
>