Re: Comments on rev ssmping-02
Stig Venaas <stig.venaas <at> uninett.no>
2008-02-04 12:56:27 GMT
Thanks for the comments Gorry. Here comes my detailed feedback which
I should have given you long ago. I really appreciate your input, I'm
now in the process of updating the draft. All the feedback I've got
from you on this and previous versions really help.
Gorry Fairhurst wrote:
> Stig & Hugo,
>
> This looks pretty good.
>
> General comments/questions
>
> 1) What happens when the size of reply exceeds a local limit on the
> message size at the server - I guess the server simply omits the
> remaining options?
That is one possibility. Another option is that the server could send
a Server Response message indicating that the client should stop. I
currently do this if the server is not happy with the client's choice
of group address and clientID in the request. However, if I send
Server Response on multiple error situations, then the response may
also need to indicate the type of error.
> 2) I think some options are mandatory to implement. Is this reflected
> by the MUST field in the table in section 5?
Pretty much. I need to think through what needs to be mandatory, and I
should make that clear.
> 3) You seem to have specified a set of message types/numbers, but did
> not define a registry to hold them. Was that a conscious decision?
I'm trying to define one for option types. I'm not sure if there should
be one for message types. Not that I mind doing a registry, just not
sure if needed.
> 4) The protocol does not provide an integrity check, which is fine. But
> I would assume that any protocol that does not have an integrity check
> would specify that the IPv4 UDP Checksum MUST be enabled.
Right, I'll add this.
> 5) I'm guessing that you are not assuming path MTU discovery, but would
> like to clarify what you expect the behaviour to be when a message
> exceeds the path MTU. Are these messages sent with DF? (suspect not), so
> they can be fragmented. That means that we can now be speaking about a
> fair number of packets per second (or bps) generated by the client and
> server.
Yes. I don't want to mandate path MTU discovery, and I want to allow
fragmentation (messages exceeding path MTU). I think it's useful to be
able to diagnose multicast problems related to fragmentation.
>
> For a 64KB packet this seems to map to 64*8kbps (twice that in the
> return direction or 128 (256 replies) for 0.5K IPv4 packets/second. I
> would not call either of these insignificant, and they could lead to
> congestion.
If the server has some local limit (as discussed above), then the
server could send a ServerMessage asking the client to stop. This
could perhaps be a possiblity if the rate is too high, not sure.
See below.
>
> I would have expected this issue to be discussed. It seems that you have
> an RTT and could measure loss, so potentially you *could* reduce the
> rate when needed - which is what I would have expected if this were a
> transport protocol (which is not really).
Right. So, I guess I should discuss this. I think I'll say that the
server implementation is free to rate limit responses, and this should
probably be under administrative control.
One possibility could be to have the server add an option saying that
responses are rate limited when that is taking place (that is, when you
don't respond to all the client messages, the server can in the next
response say that it has done rate limiting). Perhaps it's better to
keep it simple and not do this though.
More comments below.
>
> Best wishes,
>
> Gorry
>
>
>
> --- Questions on this revision ---
>
> 3.2
> - Have you considered recommending a random starting starting value for
> the SSMPING sequence number. This could offer you a way to mitigate the
> off-path DOS attack that you describe. It would also mean that a client
> that restarts would be able to disambiguate old v. new replies from the
> network. (Of course this would also make for a less intuitive packet
> field when sniffing the wire.)
I suggest I recommend that the client include some randomised value in
the ClientID. My implementation includes process ID on the client system
which partly helps.
> ---
> Timestamp.
> - Not sure about the multiple inclusion of this option in the reply.
> This seems ugly and requires a different rule in the protocol. Is it
> possible just to define a different option for the server supplied
> timestamp?
You're right. I'll use a different option. Thanks.
> ---
> Option Request
> /except that a server will/
> ^^^^
> - I think you are mandating a behaviour, should it be SHOULD or is it MAY?
> - Perhaps it would be easier to say first that clients and servers MAY
> implement the option, then say if a server implements it, it MUST...
Right, I get your point (AFAIK).
> ---
> Pad
> /the server should remove the entire pad option/
> ^^^^^^
> - Is this SHOULD or MUST?
I think I'll get rid of the entire pad option. The client can instead
use a longer ClientID if it wants to increase the message size. The
only problem is that it has less control of the response sizes, but it
also simplifies the protocol, which is good.
> ---
> Security Considerations
> /fairly harmless/ - presumably because they are sent to the SSMPING port.
The client requests are not sourced from a specific port, and the
responses are sent by the server to the port the request came from. So
an evil client can in fact make the server send unicast responses to
arbitrary addresses and ports. Is that a big problem? E.g. you can make
a DNS server send responses to arbitrary ports as well.
Attempting to use a fixed source port for all ssmping requests would
cause problems when running multiple concurrent clients on the same
host. It's possible to have each client receive multicast responses,
but not unicast.
>
>
> ====================================
> NiTs:
>
> Abstract.
> The second line of the abstract says /one can receive//.
> - actually the protocol doesn't tell the user, it informs the endpoint
> (router, host), whatever
> ---
> Architecture, para 1
> /as follows/as follows:/
> ^
> ---
> Architecture, final para:
> /and also differences in delay/
> - you already say differences in one way delay, do you mean round-trip
> delay here?
> ---
> Architecture doesn't mention tunnels - it may at least be worth
> mentioning that TTL decrements do not show tunnel router hops.
> ---
> Section 3
> /and there are some other options that/
> ^^^^
> - consider omitting some.
> ---
> Section 3
> /and then, immediately following, options/
> ^
> - consider adding "any".
> ---
> Section 3
> I'd expect the client to skip any unknown options, but I could not find
> explicit text that actually says it MUST.
Right, I need to say something about how clients and servers act on
unknown options. I want them to be ignored, except that the server
should echo back the client options.
> ---
> 3.1
> - Please add that the figures use internet byte order.
> ---
> 3.1
> - Actually the complete set of options is presumably defined by the IANA
> registry. This document only defines the set of currently defined options?
Right
> ---
> TTL
> /is not absolutely required/
> ^^^^^^^^^^ ^^^^^^^^
> - In a protcol spec, I think the language could be tighter. I'd suggest
> ommiting "absolutely" and replace not required with one of:
> NOT REQUIRED, SHOULD..., or whatever
Agree
> ---
> Session ID
> /should do/
> - Is this SHOULD or MUST?
> - I do not understand why a client is allowed to do anything other than
> echo the session id sent by the server. My suggestion is that a server
> than supports this feature MUST echo the session ID (if any) in the
> previously received request.
The intention is that the client MUST always echo back the sessionID
it got from the server. I'll make this clearer.
> ---
> Section 6
>
> - The use of RFC keywords here seems inconsistent. I'd have expected
> this section to be informative, that is working through how clients and
> servers uses the protocol procedures already defined, and I'd encourage
> you not to elaborate details here. If you do this, you may wish to move
> all SHOULD, MUST, etc to the previous section and leave this one with
> "could", "should", "must", etc.
Yes, that would be better.
> ---
> Missing references?
> - I think this document should also cite:
> NORMATIVE - UDP
> NORMATIVE - IPv6 (as UDPv6)
> INFO - UDP Guidlines
> INFO - IANA SSMPING Registry
Sounds fine.
Stig
_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
http://www.ietf.org/mailman/listinfo/mboned
)
- If it's not meant to be supported, then why not ?
Thanks
Toerless
_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
RSS Feed