OWAMP review (Was: Re: Please review documents on IESG agenda for June 9, 2005)

[Jari Arkko <jari.arkko@piuha.net>]

Wijnen, Bert (Bert) wrote:

>  o draft-ietf-ippm-owdp-14.txt
>    A One-way Active Measurement Protocol (OWAMP) (Proposed Standard) - 4 of 8 
>    Token: Allison Mankin
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