A One-way Active Measurement Protocol (OWAMP)
RFC 4656
Yes
No Objection
Abstain
Note: This ballot was opened for revision 16 and is now closed.
(Allison Mankin; former steering group member) Yes
Russ cleared after Stas did the last of the HMAC keying.
(Bert Wijnen; former steering group member) No Objection
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
(Brian Carpenter; former steering group member) No Objection
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
(Jon Peterson; former steering group member) No Objection
(Margaret Cullen; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
(Scott Hollenbeck; former steering group member) No Objection
(Ted Hardie; former steering group member) No Objection
(Sam Hartman; former steering group member) (was Yes) Abstain
I'm moving from yes to abstain because of compromises made to clear Russ's discuss.