Re: [apps-discuss] APPSDIR review of draft-ietf-behave-64-analysis-05

[<[e-mail]>]

Dear SM,

Thank you for your review.

Please see inline.

Cheers,
Med 

> -----Message d'origine-----
> De : S Moonesamy [mailto:[e-mail]] 
> Envoyé : jeudi 16 février 2012 20:48
> À : [e-mail]; 
> [e-mail]
> Cc : [e-mail]
> Objet : APPSDIR review of draft-ietf-behave-64-analysis-05
> 
> I have been selected as the Applications Area Directorate reviewer 
> for this draft (for background on appsdir, please see 
> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsArea
> Directorate ).
> 
> Please resolve these comments along with any other Last Call comments 
> you may receive. Please wait for direction from your document 
> shepherd or AD before posting a new version of the draft.
> 
> Document: draft-ietf-behave-64-analysis-05
> Title: Analysis of Stateful 64 Translation
> Reviewer: S. Moonesamy
> Review Date: February 16, 2012
> 
> Summary: This draft is almost ready for publication as an 
> Informational RFC.


> 
> This draft evaluates how the new stateful translation mechanisms 
> avoid the problems that caused the IETF to deprecate NAT-PT.  It 
> discusses about problems identified in RFC 4966.  There is an 
> analysis about an application protocol (FTP) in Section 
> 2.2.  Applications are mention in several places.  I did not find any 
> application issues.
> 
> Major issues:
> 
> None.

> 
> Minor issues:
> 
> In Section 2.2:
> 
>       "Analysis: This is not specific to NAT64 but to all stateful
>            NAT flavors.  The presence of single point of failures is
>            deployment-specific."
> 
> Wouldn't the anchoring of flows create a single point of failure?

In some deployment it can be SPOF but in others no. This depends if the a distributed NAT model is adopted, if NAT state synchronization mechanisms are enabled, etc. Do we need to clarify this in the document?

> 
>       "Actually, this is not a limitation of 64 (or even NAT-PT) but
>        a deployment context where shared IPv4 addresses managed by
>        the NAT64 are not globally reachable."
> 
> What is meant by "shared IPv4 addresses" in this context?

The IPv4 address pool used by the NAT64 to service IPv6 hosts. Several IPv6 hosts may share the same IPv4 address. Do you think this need a clarification in the document?

> 
> In Section 2.3:
> 
>     "Application clients (e.g., VPN clients) are not aware of the
>      timer configured in the NAT device.  For unmanaged services, a
>      conservative approach would be adopted by applications which
>      issue frequent keepalive messages to be sure that an active
>      mapping is still be maintained by any involved NAT64 device
>      even if the NAT64 complies with TCP/UDP/ICMP BEHAVE WG
>      specifications."
> 
> I suggest point to the relevant IETF specifications.  For what it's 
> worth, this draft becomes an IETF specification instead of a WG 
> specification once it is published as a RFC.

Ok, changed to RFC4787, RFC5382 and RFC5508.

> 
>    "Address persistence can be therefore easily ensured by the
>     NAT64 function (which complies with BEHAVE NAT recommendations
>    [RFC4787][RFC5382])."
> 
> I recommend against writing a draft from a working group perspective 
> unless it is meant for IETF consumption only.

Sorry, but I don't understand this comment. Can you please clarify? Thanks.

> 
> In Section 5:
> 
>     "This document does not specify any new protocol or 
> architecture.  It
>      only analyzes how BEHAVE WG 64 documents mitigate 
> concerns raised in
>      [RFC4966] and which ones are still unaddressed."
> 
>  From Section 1.1, I am given to understand that there are references 
> to mechanisms defined in the RFCs mentioned in that section.   There 
> isn't any mention of BEHAVE WG 64 documents.  I suggest referencing 
> the documents.

I can do but IMHO the document does not introduce new security concerns, no?

> 
> There is a normative reference to RFC 2766, which is Historic.

Moved to Informative Section.

> 
> Nits:
> 
> The Requirements language section is oddly placed.

Fixed. 

> 
> In Section 2.3:
> 
>   "Creation of a DoS (Denial of Service)"
> 
> That could be "Creation of a Denial of Service (DoS)".

Ok.

> 
> Some of the informative references are out of date.
> 
> Regards,
> S. Moonesamy
> 
>