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

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Thanks Jari for the review and Thanks to Stanislav for
the quick responses. Not sure if you decided (with your AD)
to do a new revision or not. 

Anyway, I will record the comments as COMMENTS in the ID_tracker.

Bert

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net]
> Sent: Friday, June 03, 2005 09:57
> To: shalunov@internet2.edu
> Cc: Wijnen, Bert (Bert); 'mankin@psg.com'; AAA Doctors
> Subject: OWAMP review (Was: Re: Please review documents on IESG agenda
> for June 9, 2005)
> 
> 
> 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
> 
>