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

[stanislav shalunov <shalunov@internet2.edu>]

Jari Arkko <jari.arkko@piuha.net> writes:

> >  o draft-ietf-ippm-owdp-14.txt

> 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.

http://e2epi.internet2.edu/owamp/ has an implementation you might be
able to use if you have any Linux or FreeBSD machines.  It is used to
regularly measure Internet2's backbone, Abilene, and a few other
networks, as well as for on-demand tests.

We're also aware of a Java implementation at
http://www.av.it.pt/jowamp/ and about a hardware-assisted
implementation used by APAN to measure their backbone (most recently
presented at PAM 2005, http://www.pam2005.org/PDF/34310360.pdf).

A few other groups told us about their work to implement OWAMP or
parts of it, but they haven't made their work public so far.

> 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.

Thank you for your time to review the text.  This is most helpful.

> 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.

It seems that allowing clients to send *to* the sender (or anywhere it
controls) is perfectly permissible; indeed, a client already has the
ability to send to the server (or anywhere else, for that matter) even
without OWAMP.

So, I would insert ``or the address of the server (or an address of a
host it controls'' after ``was initiated from''.  If that is done, I
believe this paragraph would be an excellent clarification that would
reinforce, with an explanation, the importance of this requirement for
the implementor.

>     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."

s/OWDP/OWAMP/

s/Sender/Receiver/
Otherwise, the server would of course have to deny it---it can't send
from somewhere it can't control.  Or is that the point?  If so, ignore
the remainder.  It seems redundant to me, but I would have no
objection if anyone finds it clarifying.

If this is the Receiver Address we're talking about:

I would also s/MUST/SHOULD/; according to RFC 2119, ``SHOULD'' means
``that there may exist valid reasons in particular circumstances to
ignore a particular item, but the full implications must be understood
and carefully weighed before choosing a different course.''

Indeed, a server might have a different mechanism to ensure the
authenticity of the request (perhaps, the OWAMP-Control connection is
protected by IPsec and the identity of the client making the request
is strongly authenticated and that identity is authorized to make this
kind of request; such situation would not be materially different from
authenticated or encrypted mode of OWAMP, with the only difference
being the layer of authentication); it is to provide for such
circumstances that ``SHOULD'' was chosen in the (now double-quoted)
text of the draft above.

I don't feel particularly strongly about this, but the situation
appears to be exactly what ``SHOULD'' seems to have been intended for,
at least according to its definition.

> >    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...

Thanks for catching this!  This should read

        this is only achieved in unauthenticated mode

(History: the format for encrypted mode used to be different, and
smaller; when that was changed so that authenticated and encrypted
mode use same-size OWAMP-Test messages, the text you caught was not
updated to reflect the change.)

> 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?

You're not missing anything.  I didn't update the text to keep the
introduction in sync with the rest...

> And I don't see a MAC field anywhere.

See section 6.8 of security considerations.  The relevant proof of
security of the construct can be found in
http://cr.yp.to/antiforgery/easycbc-20050109.pdf.

In addition, see
http://www1.ietf.org/mail-archive/web/ippm/current/msg00436.html for a
summary of a security review of the document conducted by Sam Weiler.
Sam did find a problem with OWAMP-Test (packet authentication in
authenticated mode in OWAMP-Test, described in the summary).  The use
of structured messages (that, in the case of OWAMP, avoids the problem
described in example 9.62 of Menezes et al. by making the number of
blocks in a message known after the first block is decrypted) has not
been questioned.

> >    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.

I have no preference one way or the other.  Originally, I thought we
might use things like IP numbers as the user identity in this field.
The current implementations interpret this as a user-readable string
that can be entered verbatim, so UTF-8 would be consistent with that
interpretation.

> (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.)

Is there a specific length that would make AAA easy/possible or must
it be unlimited?  If this is a question of changing 16 octets to 32,
that would be quite easy.

> > 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.

No objection (assuming the IESG is OK with burdening the IANA with
maintaining the registry).

> 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).

No objection.

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

This message is designed to be viewed in boustrophedon.