Subject: [MBONED] Re: Comments on SSMPING rev-00

From: Stig Venaas <[email-masked]>
Date: Tue, 03 Jul 2007 15:21:22 +0200

Gorry Fairhurst wrote:
> 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!

Thanks. I'm updating the draft now. See my comments below. If anyone has
other feedback on the draft, please give it to me within 1-2 days so
that I may incorporate it in the next revision. I should of course have
responded to this months ago...

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

I chose 64 because it needs to be bigger than 32 and many operating
systems use 64 anyway.
> 
> - 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?

I have already given this some thought. An option is only really needed
if either some operating system doesn't allow the value to be set (need
to set it both for unicast and multicast, unless default happens to be
64 I guess), or if in some distant future IP packets should travel more
than 63 hops. I guess it is cleaner in a way to not have it hard-coded,
but just recommend that it should at least be 64 or something.

Currently under most circumstances the server can simply echo back what
the client sent. If we add this TTL option that would change. Hence we
might want to say that 64 is the default (SHOULD NOT send option if ttl
is 64) and assume 64 if no option is present.

> ---
> 2) Does a request (or response) use PMTUD?
> - how is this decided?

No. That is PMTUD might be done by the stack, but both fragmentation and
reassembly are invisible to the application. OTOH some operating systems
do PTMUD on IPv6 multicast and it would be kind of interesting to have a
client check what the current PMTUD is for unicast and multicast. I have
thought of this also :) We could include it in the draft. Of course the
protocol is supposed to be extensible so it could be added later.

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

Right. Does it make sense to reserve an option range for vendor specific
or experimental use?

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

Yes, I'll remove this. Instead there will be a client pad option so that
the client can send large datagrams to get a response of the desired
size. One slight problem is that the may not be able to determine the
exact size the server responds in the case where the server adds options
on its own.

One possible solution is to say that if client uses padding, then the
client should get a response that is the same size (or at least not
smaller), where the server adjusts the pad size (probably shrinking it),
so that the response is the same size. However if the client pad is
less than the space needed for additional options from the server...

> ---
> 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?

It's not option types within option types. This is just a mechanism for
the client to ask the server to include certain options. It's all based
on TLVs and no nesting. Except for this option request option which
simply contains a list of option types it wants the server to include.
Let us see if this is really needed, but I think this is a fairly clean
way of asking for certain options. I don't want to create a new option
for each option that can be requested. E.g. I don't want to create a
"request server timestamp option" just to ask the server to include the
"timestamp option". I would rather have this general mechanism for
requesting a list of options.

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

Yes, version makes sense although being TLV based it is extensible. So
question is whether version can be simply a TLV, perhaps the first TLV,
or if it should be special.

It should work well for it to be the first TLV unless one later wants
to do fundamental changes like using more bits to encode the type or
the length. Using one single byte sounds safest. It would then not be
backwards compatible with the currently deployed code, but this may not
be an issue...

> 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?

As I see it alignment would result in slightly more efficient
processing and slightly more elegant code at the expanse of
packet size. Alignment might make some option definitions
slightly more complex or require use of padding options as well.
Also, the efficiency is not critical, it does not make that much
of a difference. At least to me it seems better not to force
alignment.

> ---
> 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?

I would like the client to pick a random free source port. It makes it
easy for the operating system to pick an available port, support
multiple clients running simultaneously etc.

On the server side, a fixed port seems reasonable. I've been thinking a
bit about SRV records too. It might be useful, but I don't want to make
DNS and SRV records a requirement.

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

This is the same for a lot of protocols though. I believe using a fixed
client port may make it impossible to run multiple clients, possibly by
different users, on some operating systems. I would need to look into
this, perhaps someone else knows better.

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

One interesting idea that was noted by someone else, is that perhaps the
server should pick the address. I think there is a need for a client to
at least suggest a group range though. In particular if you want to test
for a specific scope or a specific RP (the latter is particularly useful
for IPv6 with embedded-RP).

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

Yes, not sure what to do about this. I guess in some cases the server
could be configured to know which unicast addresses are within a given
scope zone so that it could know whether the client is inside the zone,
but in general this is difficult.

> ---
> 9) The name probably needs some work:-)

Suggestions welcome. mping and mcping are already taken. I guess the
protocol could have some long winded name while at least some
implementations could still use ssmping/asmping as name of the tools.

Stig

> 
> 
> 
> =================
> 
> 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

---

From: Stig Venaas <[email-masked]>
Date: Tue, 03 Jul 2007 15:21:22 +0200

Stig