Last Call Review of draft-ietf-behave-nat-behavior-discovery-
review-ietf-behave-nat-behavior-discovery-secdir-lc-cridland-2009-08-03-00

Request Review of draft-ietf-behave-nat-behavior-discovery
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-08-11
Requested 2009-03-13
Authors Derek MacDonald, Bruce Lowekamp
Draft last updated 2009-08-03
Completed reviews Secdir Last Call review of -?? by Dave Cridland
Assignment Reviewer Dave Cridland 
State Completed
Review review-ietf-behave-nat-behavior-discovery-secdir-lc-cridland-2009-08-03
Review completed: 2009-08-03

Review
review-ietf-behave-nat-behavior-discovery-secdir-lc-cridland-2009-08-03




I have re-reviewed this document as part of the security  


directorate's ongoing effort to review all IETF documents being  


processed by the IESG.  These comments were written primarily for the  


benefit of the security area directors.






Original review and response are attached, I omitted to copy the  


secdir mailing list the first time.






For -07, the document addresses the security concerns of the protocol  


extensions involved adequately. In particular:




On Tue May 26 11:28:45 2009, Dave Cridland wrote:


The Security Considerations section is reasonably complete, as far  


as  I can tell, however it is not terribly clear that it suggests   


authentication of the clients (it says "preexisting credentials") -  


I  think this could be clearer. The description of  


XOR-RESPONSE-TARGET  also doesn't include this, it's mentioned most  


clearly in Section 6.1.






This has since been clarified in -07, having been addressed by a  


clear, point-by-point mitigation guide.




Dave.


--- 

Begin Message

 ---







To

: IETF-Discussion <

ietf at ietf.org

>, <

behave-chairs at tools.ietf.org

>, <

derek at counterpath.com

>, Bruce Lowekamp <

bbl at lowekamp.net

>




Subject

: Security Review of draft-ietf-behave-nat-behavior-discovery-06




From

: Dave Cridland <

dave.cridland at isode.com

>




Date

: Tue, 26 May 2009 11:28:45 +0100







I have reviewed this document as part of the security directorate's  


ongoing effort to review all IETF documents being processed by the  


IESG.  These comments were written primarily for the benefit of the  


security area directors.  Document editors and WG chairs should treat  


these comments just like any other last call comments.




(I note there is expected to be a new version coming for this draft).

Security Issues:



The Security Considerations section is reasonably complete, as far as  


I can tell, however it is not terribly clear that it suggests  


authentication of the clients (it says "preexisting credentials") - I  


think this could be clearer. The description of XOR-RESPONSE-TARGET  


also doesn't include this, it's mentioned most clearly in Section 6.1.




General comments:



I have a strong suspicion that this document is Experimental purely  


because it failed to gain sufficient consensus to be Standards-Track.  


It's not clear to me why this is not Informational, or why all the  


extensions described in the document are within the same document.  


I'm dubious that they're all of similar quality.






If there is an experiment here, then it's in the usage of these  


extensions to determine whether, at least in some cases, NAT  


behaviour is sufficiently stable as to be useful, and moreover,  


whether taking advantage of this is practical. The extensions  


themselves clearly seem suitable for discovering whether this is so.






As such, section 2.3 seems somewhat contrived and grasping. This  


isn't to say that the hypothesis being tested is not valid, but the  


experiment, as defined, seems like a matter of form rather than a  


useful test of the hypothesis as outlined.




Editorial Issues:



The use of the term "aprocyphal" is interesting, but conjures up  


connotations that seem to be somewhat self-defeating. Perhaps  


"anecdotal" would be more fitting, or "controversial". (It is this  


evidence, after all, that forms the hypothesis mentioned above, and  


the hypothesis itself is surely not aprocypha).






IANA section requests registration of CHANGE-REQUEST, but this is  


already registered - the registration needs changing, as per section  


6.1, where the situation is detailed more clearly.




Typographical Errors:

Extraneous "}" in section 9.4.



--- 

End Message

 ---




--- 

Begin Message

 ---







To

: Dave Cridland <

dave.cridland at isode.com

>




Subject

: Re: Security Review of draft-ietf-behave-nat-behavior-discovery-06




From

: Bruce Lowekamp <

bbl at lowekamp.net

>




Date

: Tue, 7 Jul 2009 22:39:33 -0400




Cc

: IETF-Discussion <

ietf at ietf.org

>, behave-chairs <

behave-chairs at tools.ietf.org

>, 	derek <

derek at counterpath.com

>, 

behave at ietf.org




In-reply-to

: <

27466.1243333725.022789 at puncture

>




References

: <

27466.1243333725.022789 at puncture

>







Dave,

Thanks for the feedback.   Responses inline.


On Tue, May 26, 2009 at 6:28 AM, Dave Cridland<dave.cridland at isode.com> wrote:
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the security area
> directors.  Document editors and WG chairs should treat these comments just
> like any other last call comments.
>
> (I note there is expected to be a new version coming for this draft).
>
> Security Issues:
>
> The Security Considerations section is reasonably complete, as far as I can
> tell, however it is not terribly clear that it suggests authentication of
> the clients (it says "preexisting credentials") - I think this could be
> clearer. The description of XOR-RESPONSE-TARGET also doesn't include this,
> it's mentioned most clearly in Section 6.1.

I made a lot of edits around XOR-RESPONSE-TARGET, in the process I
actually removed the phrase "pre-existing credentials", just leaving
it as authenticated.  However, the term comes from 5389, which only
defines mechanisms for using "pre-existing credentials" for
authentication, meaning credentials that are obtained through a
mechanism outside STUN itself.

>
> General comments:
>
> I have a strong suspicion that this document is Experimental purely because
> it failed to gain sufficient consensus to be Standards-Track. It's not clear
> to me why this is not Informational, or why all the extensions described in
> the document are within the same document. I'm dubious that they're all of
> similar quality.
>
> If there is an experiment here, then it's in the usage of these extensions
> to determine whether, at least in some cases, NAT behaviour is sufficiently
> stable as to be useful, and moreover, whether taking advantage of this is
> practical. The extensions themselves clearly seem suitable for discovering
> whether this is so.
>
> As such, section 2.3 seems somewhat contrived and grasping. This isn't to
> say that the hypothesis being tested is not valid, but the experiment, as
> defined, seems like a matter of form rather than a useful test of the
> hypothesis as outlined.

Section 2.3 doesn't describe an experiment, it describes conditions
for experimental success.  Section 2.2 has been greatly expanded and
now describes in much more detail how such an application might work.
However, it's not the only application that could satisfy the
conditions.

>
> Editorial Issues:
>
> The use of the term "aprocyphal" is interesting, but conjures up
> connotations that seem to be somewhat self-defeating. Perhaps "anecdotal"
> would be more fitting, or "controversial". (It is this evidence, after all,
> that forms the hypothesis mentioned above, and the hypothesis itself is
> surely not aprocypha).

Another reviewer also brought this up.  Technically, "aprocryphal"
could be interpreted as being contrary to IETF dogma, but I think
you're right that anecdotal is clearer here.

>
> IANA section requests registration of CHANGE-REQUEST, but this is already
> registered - the registration needs changing, as per section 6.1, where the
> situation is detailed more clearly.
>

Numerous attempts by myself and others to determine the right way to
handle this have indicated that this is the appropriate way to handle
this, as the original registration has been obsoleted.  But I'm always
open for advice as to the best way to handle it.

Bruce


--- 

End Message

 ---