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

From: S Moonesamy <[email-masked]>
Date: Thu, 16 Feb 2012 11:47:30 -0800

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/ApplicationsAreaDirectorate ).

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?

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

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.

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

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.

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

Nits:

The Requirements language section is oddly placed.

In Section 2.3:

  "Creation of a DoS (Denial of Service)"

That could be "Creation of a Denial of Service (DoS)".

Some of the informative references are out of date.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Thu, 16 Feb 2012 23:57:04 -0800

Hi Med,
At 22:51 16-02-2012, [email-masked] wrote:
>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?

It would help the reader if that could be clarified.

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

I recommend a clarification as there is a proposal about shared address space.

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

If we are talking about the BEHAVE WG, IETF participants either know 
about it or can look it up.  If you say "which complies with BEHAVE 
NAT", a wider audience would not know what BEHAVE is.  It's easier to 
say "complies with NAT recommendations in [RFC4787][RFC5382]".

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

I don't think so but I'll defer to the Security Directorate on this.

Thanks for the feedback.

Regards,
S. Moonesamy

---

From: <[email-masked]>
Date: Fri, 17 Feb 2012 07:51:44 +0100

Dear SM,

Thank you for your review.

Please see inline.

Cheers,
Med 

> -----Message d'origine-----
> De : S Moonesamy [mailto:[email-masked]] 
> Envoyé : jeudi 16 février 2012 20:48
> À : [email-masked]; 
> [email-masked]
> Cc : [email-masked]
> Objet : APPSDIR review of draft-ietf-behave-64-analysis-05
> 

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

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

> specification once it is published as a RFC.

Ok, changed to RFC4787, RFC5382 and RFC5508.

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

Moved to Informative Section.

> The Requirements language section is oddly placed.

Fixed. 

> That could be "Creation of a Denial of Service (DoS)".

Ok.

---

From: <[email-masked]>
Date: Fri, 17 Feb 2012 10:15:59 +0100

Re-,

Thank you for the clarifications. I updated the document accordingly.

Cheers,
Med 

> Envoyé : vendredi 17 février 2012 08:57
> À : BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]; 
> Objet : RE: APPSDIR review of draft-ietf-behave-64-analysis-05
> 
> Hi Med,