Skip to main content

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

Yes


No Objection

(Bill Fenner)
(David Kessens)
(Jon Peterson)
(Margaret Cullen)
(Russ Housley)
(Ted Hardie)

Abstain


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

(Allison Mankin; former steering group member) Yes

Yes (2006-03-19)
Russ cleared after Stas did the last of the HMAC keying.

(Bert Wijnen; former steering group member) No Objection

No Objection (2005-06-09)
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

(Bill Fenner; former steering group member) No Objection

No Objection ()

                            

(Brian Carpenter; former steering group member) No Objection

No Objection (2005-06-09)
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.

(David Kessens; former steering group member) No Objection

No Objection ()

                            

(Jon Peterson; former steering group member) No Objection

No Objection ()

                            

(Margaret Cullen; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection (2006-03-07)

                            

(Scott Hollenbeck; former steering group member) No Objection

No Objection (2005-06-06)
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.

(Ted Hardie; former steering group member) No Objection

No Objection ()

                            

(Sam Hartman; former steering group member) (was Yes) Abstain

Abstain (2006-03-19)
I'm moving from yes to abstain because of compromises made to clear
Russ's discuss.