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

[MBONED] Comments on rev ssmping-02

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?

2) I think some options are mandatory to implement. Is this reflected
by the MUST field in the table in section 5?

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?

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.

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.

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.

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

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.)
---
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?
---
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...
---
Pad
/the server should remove the entire pad option/
            ^^^^^^
- Is this SHOULD or MUST?
---
Security Considerations
/fairly harmless/ - presumably because they are sent to the SSMPING port.


====================================
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.
---
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?
---
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
---
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.
---
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.
---
Missing references?
- I think this document should also cite:
NORMATIVE - UDP
NORMATIVE - IPv6 (as UDPv6)
INFO - UDP Guidlines
INFO - IANA SSMPING Registry





_______________________________________________
MBONED mailing list
MBONED at ietf.org
https://www1.ietf.org/mailman/listinfo/mboned