Subject: [MBONED] Comments on SSMPING rev-00

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 26 Mar 2007 14:34:25 +0100

SSMPING rev-00

I'd like to support this as a work item in mboned. This seems like a useful
tool and one that the people in mboned can contribute. Thanks for making the
draft!

Best wishes,

Gorry

Some questions/comments follow:

---
1) TTL
Introduction, para 1
- why is TTL fixed at 64?
- Not that this seems a silly value, or anything, just that it is a
hard-wired value, and some justification is probably needed.

- Could the TTL of the response be set differently by the server?
- It would not be hard to have a parameter with original TTL, as in
Quick-Start.
- If so, in what cases does this make sense?
---
2) Does a request (or response) use PMTUD?
- how is this decided?
---
3) Registries
The current spec has at least two set of code-points. Normal IETF practice
would assume that IANA code point registries are created to hold these
values.
That would also add to section 6.
---
4) Response Size
This worries me a little. I do not think it is good practice to have  a
response that can create a packet bigger than the expected MSS. If this is
in the tool, it raises some very significant packet-amplification features
(through fragmentation) that create more DoS opportunities.
---
5) Option Type
I am not sure why the document speaks of option types, within option types.
I would have thought a cleaner design would emerge from having just one
level of code-points to be parsed and maintained. Having an option contain a
list of options seems odd - can you explain?
---
6) Protocol Header
There is no protocol version code. This seems Odd. If this is an
IETF-defined protocol, let's give ourselves the chance to maintain this.
Could we start with a 1-byte version field. This also gives 16-bit
alignment. I can see someone asking why we don't use a 32-bit aligned base
header, and that also seems a reasonable question to me?
---
7) Security Considerations
/This is fairly harmless/
- Not so (yet), IMHO there are some issues that need to be fixed in the
protocol design:
* An arbitrary port, raises the question of what happens if that port is in
use on the server/client? - Since this is a debugging tool, it would be nice
to think one could use it without some session level agreement between
sender and receiver... (someone doing DoS would not worry about this
nicety). Are there other considerations about the port?
* A unicast response sent to a third party (i.e. to a spoofed source
address) somewhere in the internet on a port that you decide seems a recipe
for security problems.
---
8) Group Addresses
* Group address range could also be limited, at least noting that it does
not make sense to use this tool in all group ranges.
* So, I'm confused about what happens with scoped-address usage, is there a
possibility that the unicast ssmping request transits a network boundary and
then responds with a multicast packet which has the requested address but a
differently interpreted multicast scope, leading to non-delivery of the
multicast packet? Some guidance on use may be useful.
---
9) The name probably needs some work:-)

=================

NiTs (minor stuff to note for the author's next rev)

---
Abstract:
- Define SSM.
---
Introduction, para 1
/in order to serve request from/to serve a request from/
---
Introduction, para 2
/first of all/first/
---
Section 3
/Most of the options/Most options/
/doesn't/does not/
/Strictly speaking the protocol/The protocol/
/can obtain a lot more information/can obtain more information/
/response to be of a certain size/response to be of a certain minimum size/
/should however nit try to make/ --- language seems odd. Is it not possible
to use a SHOULD or MUST here, to be concrete?
/the options follow right after/the options directly follow/
---
References are rather short in the first draft.
---

_______________________________________________
MBONED mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mboned