A One-way Active Measurement Protocol (OWAMP)
RFC 4656

Note: This ballot was opened for revision 16 and is now closed.

(Allison Mankin) Yes

Comment (2006-03-19)
No email
send info
Russ cleared after Stas did the last of the HMAC keying.

(Brian Carpenter) No Objection

Comment (2005-06-09 for -)
No email
send info
Frome review by Mark Allman.The first and last points certainly need attention.

  + On page 8 it would seem like the mode value should be chosen from
    the mode values advertised in the message given on page 7.  Right?
    I think it'd be good to say this.

  + The MBZ fields are often mentioned in the context of filling them in
    with a "string" of zeros.  I think a better word could be chosen
    here.  I understand that we're not really placing a string in the
    packet.  But, more explicitly stating that each bit must be of value
    zero would be nice.  (This is a nit and maybe something that could
    be clarified by the RFC editor.)

  + Another nit... "uptime" seems like the wrong term.  I think
    "StartTime" would be better since this is an absolute time and not a
    relative time.  I.e., it's when the process started, not how long it
    has been running.  (Right?)  (Again, could be fixed with an RFC
    editor note, I am sure.)

  + I am baffled as to the purpose of the IZP field.  I think there
    needs to be a better paragraph as to what the purpose of this field
    really is.

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

(Ted Hardie) No Objection

(Scott Hollenbeck) No Objection

Comment (2005-06-06 for -)
No email
send info
Intro:
"The IETF IP Performance Metrics (IPPM) working group has proposed
draft standard metrics for one-way packet delay [RFC2679] and loss
[RFC2680] across Internet paths."

2679 and 2680 are PROPOSED (not draft) standards.

(Russ Housley) (was Discuss) No Objection

(David Kessens) No Objection

(Jon Peterson) No Objection

(Bert Wijnen) No Objection

Comment (2005-06-09 for -)
No email
send info
Review comments from a AAA-Doctor (Jari) and author/editor has
agreed (to at least part of it) and I think has revised text.

--- comments from Jari follows:

I read this draft based on Bert's request. 
Here are my comments:

Overall:

I like this draft, its very exciting technology. I'm eager to
start testing it, when it becomes available on the types
of machines that I use.

The draft is mostly OK. I noted some nits. The main
technical concern I have is tighting up the denial-of-service
protection text.

Note that I'm not a IPPM expert and this is the first time I
read this draft. I may have missed something obvious. If
so, let me know.

Technical:

> 6.2. Preventing Third-Party Denial of Service
>
>    OWAMP-Test sessions directed at an unsuspecting party could be used
>    for denial of service (DoS) attacks.  In unauthenticated mode,
>    servers SHOULD limit receivers to hosts they control or to the OWAMP-
>    Control client.

The above text is good, but I would like to tighten the rule
a little bit. Maybe by adding this:

   "Specifically, unless otherwise configured, the default behavior
    of servers MUST be to decline requests where the Receiver Address
    field is not equal to the address that the control connection
    was initiated from. Given the TCP handshake procedure and sequence
    numbers in the control connection, this ensures that the hosts that
    make such requests are actually those hosts themselves, or at
    least on the path towards them. If either this test or the handshake
    procedure were omitted, it would become possible for attackers
    anywhere in the Internet to request large amounts of test packets
    be directed against victim nodes somewhere else.

    In any case, servers MUST decline all requests where the Sender
    Address is not either the server's own address or the address of
    a node that it controls; OWDP-Test packets with a given source
    address can only be sent from the node that has been assigned
    that address."

>    payload of a single ATM cell (this is only achieved in
>    unauthenticated and encrypted modes).

I have to wonder whether this should read "unauthenticated
and unencrypted", but I'm reading on... Section 4.1.2 shows
the authenticated and encrypted modes to have the same
format, and neither EBC or CBC modes should add any
overhead. What am I missing? Why does an encrypted mode
packet fit an ATM cell but an authenticated does not? And
I don't see a MAC field anywhere.

>    The protocol does not carry any information in a natural language.

I would actually prefer the Username field to be in UTF-8, rather
than Octet. (It would be even better if it were possible to have
longer than 16 byte usernames, in case someone later wants to
use AAA or something for the shared secret management of
OWDP. But I can see that changing that would be a too big change
for the protocol formats.)

> 7. IANA Considerations
>
>    IANA is requested to allocate a well-known TCP port number for the
>    OWAMP-Control part of the OWAMP protocol.

How about Accept values? Might make sense to have a rule about adding
those. Say, Standards Action.

Editorial:

>  hosts
>    increasingly have available to them very accurate time
>    sources

Maybe "very accurate time sources are increasingly available
to hosts", which sounds better to me (but I'm not a native speaker).

--Jari

(Sam Hartman) (was Yes) Abstain

Comment (2006-03-19)
No email
send info
I'm moving from yes to abstain because of compromises made to clear
Russ's discuss.