draft-ietf-ippm-more-twamp-02.txt

2009-06-02 Thread Donald Eastlake
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This draft does two things in connection with the Two-Way Active
Measurement Protocol (TWAMP) a protocol which builds on the One-Way
Active Measurement Protocol (OWAMP):
 (1) Add an extension whereby the TWAMP-Test protocol can be done
in an unauthenticated mode while TWAMP-Control is authenticated and
encrypted, where previously they had been required to have the same
security mode. TWAMP-Control is used to initiate, start, and stop,
etc. test sessions, while TWAMP-Test is used to exchange test packets.
 (2) The draft establishes an IANA registration called TWAMP-Modes
for adding features. Establishing the IANA registry as such is not
security relevant.

This draft has a brief Security Considerations section. It
incorporates by reference the lengthy Security Considerations in RFC
4656, which specified OWAMP, and from RFC 5357, which specifies TWAMP
and adds considerations for one DoS attack which overlooked in RFC
4656. Generally, this incorporation by reference is adequate.

However, the draft Security Considerations sections has one additional
sentence which includes the words thus making it possible to increase
overall security when compared to the previous options. That would
only be true if the additional burden, under previous options where
both control and test had the same security mode, of securing both
TWAMP-Control and TWAMP-Test was prohibitive, forcing less security
for TWAMP-Control and where having TWAMP-Test unauthenticated is not a
problem with respect to the security threats in the particular
instance. I believe the Security Considerations section should be
re-worded to either drop the claim of increase overall security or
at least make it clear that the claim only applies under resource
constraints that would, under previous modes, have forced less
security for TWAMP-Control and where unauthenticated TWAMP-Test is not
a significant security concern.

Thanks,
Donald
=
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e...@gmail.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Last Call: draft-ietf-ippm-more-twamp (More Features for the Two-Way Active Measurement Protocol - TWAMP) to Proposed Standard

2009-05-05 Thread The IESG
The IESG has received a request from the IP Performance Metrics WG 
(ippm) to consider the following document:

- 'More Features for the Two-Way Active Measurement Protocol - TWAMP '
   draft-ietf-ippm-more-twamp-01.txt as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
i...@ietf.org mailing lists by 2009-05-19. Exceptionally, 
comments may be sent to i...@ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ippm-more-twamp-01.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17788rfc_flag=0

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


Draft-ietf-ippm-more-twamp

2009-04-22 Thread Henk Uijterwaal

Dear IETF secretariat,

The IPPM group would like to ask for publication of draft-ietf-ippm-more-twamp
as an RFC.  The shepherd note for the document is attached.

Henk

- - - -

Document shepherd writeup for draft-ietf-ippm-more-twamp-00, as required by
rfc4858, and specfied in the 17-Sep-2008 version of
http://www.ietf.org/IESG/content/Doc-Writeup.html.

(1.a) Who is the Document Shepherd for this document? Has the
  Document Shepherd personally reviewed this version of the
  document and, in particular, does he or she believe this
  version is ready for forwarding to the IESG for publication?

The document shepherd is Henk Uijterwaal h...@ripe.net.  I have personally
reviewed this document and would not have bothered to write this note if I
didn't feel it was ready for the IESG.

(1.b) Has the document had adequate review both from key WG members
  and from key non-WG members? Does the Document Shepherd have
  any concerns about the depth or breadth of the reviews that
  have been performed?

I believe the document has received sufficent review from WG members.
This is a small extension to a thoroughly reviewed protocol.  I have no
concerns about the depth or breadth of reivews for this document.

(1.c) Does the Document Shepherd have concerns that the document
  needs more review from a particular or broader perspective,
  e.g., security, operational complexity, someone familiar with
  AAA, internationalization or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or
  issues with this document that the Responsible Area Director
  and/or the IESG should be aware of?

None.

  Has an IPR disclosure related to this document been filed?

No.

(1.e) How solid is the WG consensus behind this document? Does it
  represent the strong concurrence of a few individuals, with
  others being silent, or does the WG as a whole understand and
  agree with it?

This is an extension to an existing protocol (TWAMP, RFC 5357).  The issue
came up when the TWAMP protocol was close to completion.  As the WG wanted
to finish TWAMP, it was decided to put possible extensions in another
document.  TWAMP is actively being used by several groups these days,
none of them raised any issues with the document.  The document authors are
both involved with 2 of the implementations of the protocol and would
have flagged any issues.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?

No.

(1.g) Has the Document Shepherd personally verified that the
  document satisfies all ID nits?

There are the following issues:

  ** It looks like you're using RFC 3978 boilerplate.  You should update this
 to the boilerplate described in the IETF Trust License Policy document
 (see http://trustee.ietf.org/license-info), which is required from
 December 16, 2008.  Version 1.34 of xml2rfc can be used to produce
 documents with boilerplate according to the mentioned Trust License
 Policy document.

It is not clear to me if this is correct, as the document was submitted
before Nov 10 (i.e. pre-5378).

  == Missing Reference: '0-31' is mentioned on line 257, but not defined

This looks like an error in the tool.

  == Unused Reference: 'RFC2434' is defined on line 292, but no explicit
 reference was found in the text

  ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226)

This reference can go.


  Has the document met all formal review criteria it needs to, such
  as  the MIB Doctor, media type and URI type reviews?

None of these are necessary.

(1.h) Has the document split its references into normative and
  informative?

Yes, the informative reference section can be removed on publication as
there are none.

  Are there normative references to documents that
  are not ready for advancement or are otherwise in an unclear
  state?

No.

(1.i) Has the Document Shepherd verified that the document IANA
  consideration section exists and is consistent with the body
  of the document?

There is an IANA considerations section, it is consistent.

(1.j) Has the Document Shepherd verified that sections of the
  document that are written in a formal language, such as XML
  code, BNF rules, MIB definitions, etc., validate correctly in
  an automated checker?

Not applicable.

(1.k) The IESG approval announcement includes a Document
  Announcement Write-Up. Please provide such a Document
  Announcement Write-Up? Recent examples can be found in the
  Action announcements for approved documents. The approval
  announcement contains the following sections:

  Technical Summary

   The IETF has completed its work on TWAMP - the Two-Way Active
   Measurement Protocol