Subject: Re: [BEHAVE] APPSDIR review of draft-ietf-behave-64-analysis-05

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

---

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,
> 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.
> 
> 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 don't think so but I'll defer to the Security Directorate on this.
> 
> Thanks for the feedback.
> 
> Regards,
> S. Moonesamy 
> 
>

---

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

Summary: This draft is almost ready for publication as an Informational RFC.

Major issues:

None.

Minor issues:

In Section 2.2:

In Section 2.3:

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

Nits:

In Section 2.3:

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:
>mechanisms are enabled, etc. Do we need to clarify this in the document?

>this need a clarification in the document?

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

Thanks for the feedback.

Regards,
S. Moonesamy