[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Hi Stanislav,

And thanks for your response! Some further discussion
inline:

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.


Interesting. I'll try that at some point in time.

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.


Yes.

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.


Right. I missed that.

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.


The sender is instructed to send a set of IP packets from
a given Sender Address. My point was to make it explicit that
the node shall only send such packets if it actually has that
address. That is, do not send packets with source=X just
because the command said so... I know this is obvious. But
I've found that its often useful to be very explicit in what tests
implementations must do in a particular situation, because otherwise
they tend to be forgotten...

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


Ok.

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.


I like making certain security things mandatory, but I think
you argued well above that a should is sufficient. But there
was other part in my suggested text, which was really about
making it more explicit what an implementation needs to
check, like the IP addresses.

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.


Yes. Let me explain the background for my initial thoughts
why UTF-8, or more generally, user-readable strings, might
be appropriate. The main reason is that if people deploy
the secure mode, they are likely to want to group several
things under the same username 'handle', such as ssh account,
owamp account, etc. Being able to use the same kind of
a name would be beneficial, particularly if there is no real
other reason to use a binary string instead.

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


I'm just thinking about the (perhaps remote) possibility that
you have a number of boxes that all want to provide secure
OWAMP, and then you might want to connect this to AAA so
that you can centralize management of the usernames and
secrets. (There may be other obstacles here besides the names,
but I considered those future problems.)

The thing is, I'm not sure I have a good size to recommend.
If you have a user@domain type of a name typically used over
AAA, then according to current standards it should be at least
72 bytes though in practise less would suffice. But I wouldn't want
to add a 64 or even 32 fixed size field to a protocol, it would look
a bit silly. So that's why I said changing it is probably not what
we want. With 16 bytes you'll still fit in all usernames, but not
domain parts. But I guess this is not the application that you'd
be using roaming with anyway :-)

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


Ok.

--Jari