Subject: [MBONED] draft-venaas-mboned-ssmping-00 comments

From: Pekka Savola <[email-masked]>
Date: Sun, 18 Mar 2007 22:11:32 +0200 (EET)

Hi,

I've already discussed some of this with Stig, but some others may 
also have something to comment.

substantial
-----------

First of all, let me say I like the 'asmping' functionality; SSM part 
is trivial enough, and debugging SSM connectivity is easy enough given 
that there are no SPT switchovers, RPs, MSDP, etc.  Hence, the primary 
benefit of this tool is for ASM debugging and it should not be 
removed; rather it should be made more prominent in the specification.

    It is
    currently left open which port the request is sourced from, whether
    this port should be standardised or not.

==> it probably doesn't need to be.  The problem with specifying it 
would be that multiple clients on the same system (same IP address) 
would have troubles using ssmping simultaneously.   The advantage 
appearently is that responses could be aggregated by the server but I 
doubt that's very helpful, and it would lessen the diagnostics value 
of the tool.

3.2. Defined Options

==> I'd consider organizing these (and the future option ranges, if
left for IANA to allocate, might be a good idea..) slightly 
differently, for example based on mandatory/optional or whether it's 
used by clients or servers.  Another alternative for better 
representation might be putting these in a table.

    Multicast group, type 4.  Length MUST be greater than 1.  It is
    optional for clients and servers to support this.  It allows a client
    to specify which group the server should send to.  This is currently
    used by a tool called "asmping" to test ASM connectivity.  The server
    may have restrictions on which groups can be used.  The format of the
    option value is as below.

==> more specification is needed on which groups would be accepted as 
this could be used to DoS third parties.  At the very least this 
should be a multicast address.  Additionally some kind of rate-limiter 
might be sufficient because receivers can only be DoSed if they are 
receiving a group.  The server may come under DoS (e.g., by specifying 
link-local or network-control blocks such as VRRP or PIM routers 
multicast address) but that may be a problem of the server 
administrator.

    Version, type 6.  Length MUST be non-zero.  Supporting this option is
    optional.  A server supporting this option SHOULD add it if and only
    if requested by the client.  The value is just unformatted text that
    might contain vendor and version information for the server
    implementation.  It may also contain information on which options the
    server supports.

==> 'unformatted text'.  This has internationalization issues.  Which 
encoding is used?  Ascii, UTF-8, ..?

    Reply size, type 7.  Length MUST be 2 octets.  This option is
    optional for clients and servers.  It can be used to request the
    server response to be of a certain size.

==> It's not clear why this exists in this manner.  The client could 
just induce the server to send large packets by including pads in the 
request.

Speaking of which, maybe the specification whether the server must 
echo the request back or not may need to be better specified.

Another consideration is how/whether the protocol should support PMTU 
probing for downstream path (could require an option on 
setting/clearing DF bit etc).  It could be useful to discover the PMTU 
in the downstream paths (which may be higher than the unicast 
client->server PMTU, though this cornercase may not be important 
enough).

7. Security Considerations

==> this should also discuss the implications of requesting bigger 
response and requesting the ASM group address here.  First of all, 
requesting bigger response might not be acceptable as I guess you 
could create an amplification attack with this: ~40 byte request, 
unicast+multicast response of 64KB?  Not good.  Second, specifying the 
group address (if it doesn't check it's multicast) would be another 
3rd party DoS attack vector.

editorial
---------

   The client joins an SSM channel (S,G)
    where S is a unicast address of the server, and G is a standardised
    multicast group for use by ssmping.

==> this may require rewording as SSM-range in IPv4 doesn't specify 
standardization mechanism..

    Length (2 octets) specifies the length of the value.  Depending on
    the option type it can be from 0 to 65535.

==> s/the value/Value in octets/

    Value.  The value must always be of the specified length.  See the
    respective option definitions for possible values.  If the length is
    0, the value field is not included.

==> an explicit statement about option padding might be good here 
(most options seem to be on byte boundary only)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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