Re: [pim] pim-sm-v2-new-09 comments

[Pekka Savola <[e-mail]>]

Hi,

Another minor (but important) nit that I noticed: the document should 
say, in abstract/introduction, that is obsoletes RFC2362.

On Wed, 24 Mar 2004, Pekka Savola wrote:
> I already raised one specific issue, some others below...
> 
> substantial
> -----------
> 
>  1) I've raised this issue in the past, but I think it would be appropriate
> to explicitly describe how PIM is run inter-domain at the protocol overview
> section -- or just state that it's out of scope for this specification ??
> 
>  2) statement in 4.1.6, on page 25, says:
> 
> RPF'(*,G) and RPF'(S,G) indicate the neighbor from which data packets
> should be coming and to which joins should be sent on the RP tree and
> SPT respectively.
> 
>  .. but based on on the security analysis draft, and comments made at MBONED
> at IETF59, this is not correct.  Data packets are checked only to come from
> the _interface_ towards the neighbor, right?
> 
>  3) there are slight inaccuracies with TTL/Hop Limit of the register
> tunnell, like:
> 
> Just like any forwarded packet, the TTL of the original data packet is
> decremented after it is decapsulated from the Register Tunnel.
>                                                                           
> ==> TTL is only decremented if the data packet is forwarded out of the box. 
> I.e., if the data packet was to be terminated at the router, it would not be
> decremented.
> 
> ==> the same applies to encapsulation to register tunnel.  TTL is only
> decremented if it was _forwarded_ to the register tunnel -- but not if it
> was *originated* to the register tunnel (e.g., the router itself sending the
> packet to a group). {section 4.10.3}
> 
>  4) Is there any fundamental reason (broken implementations?) why you're
> explicitly allowing invalid destination IP addresses, rather than the
> multicast address, on a link:
> 
> On unnumbered interfaces on point-to-point links, the router's address
> should be the same as the source address it chose for the Hello message
> it sent over that interface.  However on point-to-point links we also
> recommend that PIM Join/Prune messages with a destination address of all
> zeros are also accepted.
> 
> .. this seems strange to me... (same in other places..)
> 
>  5) Section 4.7 on multicast border router behaviour describes the case
> where PIM and non-PIM multicast domains should operate.  However, section
> 4.8 abuse this section to expand that to describe how the operation between
> different PIM domains functions.  The latter should be more clearly separate
> from interworking with non-PIM protocols.
> 
>  6) The issue raised in a separate mail about wildcard receivers, that is:
> 
> o Another component of the PMBR is a wildcard receiver.  In this case
>   the PIM-SM component of the PMBR must ensure that traffic from all
>   internal sources reaches the PMBR until it is informed otherwise.
> 
> ...
> 
> In the former case, the PMBR will need to send a Join(*,*,RP) to all the
> RPs in the PIM-SM domain.  This will cause all traffic in the domain to
> reach the PMBR.  The PMBR may then act as if it were a DR with directly
> connected receivers, and trigger the transition to a shortest path tree
> (see Section 4.2.1).
> 
> ==> this presumes that PMBR is aware of all the transmissions in the
> world(!!), and fails e.g. with SSM or Embedded-RP.  As already mentioned,
> this is a very dangerous capability DoS-wise as well.
> 
>  7) Section 4.8 contains a technically unverifiable statement:
> 
> Any RP address configured or learned MUST be a domain-wide reachable
> address.
> 
> .. the implementations have no way of ensuring this, so this sounds more
> like an operational requirement.  Maybe adequate health warnings should be
> added, like:
> 
>          Note that in general, it is impossible to verify that the RP
>   address is in fact reachable, making this requirement practically
>   moot.
> 
>  8) is the implementation of Address List option left to the discretion of
> the implementor?  I'd say it's a SHOULD at least, if not a MUST:
> 
>      Unknown options may be ignored.  The "Holdtime" option MUST be
>      implemented; the "DR Priority" and "Generation ID" options SHOULD
>      be implemented.
> 
>  9) Is there anything preventing the Prune Pending Timer to be shorter than
> Join Pending time?  AFAICS, the basics how these are formed are the same. 
> This would be highly disadvantageous if someone randomized the time for Join
> Pending to be e.g. 1.0 seconds and Prune Pending to 0.8 seconds -- and state
> would be removed before the Join would be sent?
> 
> 10) Nowhere does it specify the reception rules for the packets sent, just
> the rules which must be used for sending the packets.  For example, if
> someone sent you a PIM packet, over unicast, MUST it be discarded.  These
> should probably be formally specified. This stems from:
> 
> 11) DoS descriptions in section 6.4 appear to be rather weak at this 
> point yet.  I would refer informationally 
> to draft-savola-mboned-mroutesec-00.txt (soon
> draft-ietf-mboned-mroutesec-00.txt), at least.
> 
> These two attacks should probably be described a bit more.
> 
> Additional one, described at the separate note, is the Multicast Border
> attack: if you can associate yourself as a multicast border with a router,
> you can make it send all groups in the Internet to you using a (single?)
> message with a wildcard join.  That must be spelled out unless the wildcard
> join is removed from the spec.
> 
> 12) references;
> 
> [9] should probably be Informational; it is not critical in the text, and it
> could create a blockage. [7] should probably also be Informational. [1] is
> Informational and cannot be referred Normatively by PS; recommend moving to
> info references, as it seems appropriate there.
> 
> 
> 6.1.1.  Forged link-local messages
>                                                                           
> Join/Prune, Hello, and Assert messages are all sent to the link-local
> ALL_PIM_ROUTERS multicast addresses, and thus are not forwarded by a
> compliant router.  A forged message of this type can only reach a LAN if
> it was sent by a local host or if it was allowed onto the LAN by a
> compromised or non-compliant router.
> 
> 
> 
> semi-editorial
> --------------
> PIM-SM routers need to know the address of the RP for each group for
> which they have (*,G) state.  This address is obtained either through a
> bootstrap mechanism or through static configuration.
> 
> ==> replace add "automatically, " before "bootstrap" (embedded-RP case)
> 
>                o Last RPF Neighbor towards RP that was used
>                                                                              
> ==> this may be more than just an editorial issue, but would this be better
> stated: "Last RPF Neighbor that was used towards RP" ?  (same in many other
> places.)
> 
>      void
>      CheckSwitchToSpt(S,G) {
>        if ( ( pim_include(*,G) (-) pim_exclude(S,G)
>               (+) pim_include(S,G) != NULL )
>             AND SwitchToSptDesired(S,G) ) {
>               restart KeepaliveTimer(S,G);
>        }
>      }
> 
> ==> you just indicate the desire for switchover, but do not actually
> initiate the switchover (here or in the definition of switchover) ?
> 
>      neighbor.dr_priority
>           The DR Priority field of the PIM neighbor if it is present in
>           the Hello message.
> 
> ==> and otherwise, if it is not present, dr_priority is ....?  It must be
> initialized to something, I guess..
> 
>       for each neighbor on interface I {
>           if ( neighbor.lan_delay > delay ) {
>               delay = neighbor.lan_delay
>           }
>       }
> 
> ==> you should probably clarify, (actually earlier but this is an example of
> this), that the router must keep its own values on record as well ..
> essentially considering it as a neighbor as well on all of its interfaces,
> right?
> 
> Within one Address List Hello option, all the addresses MUST be of the
> same address family.  It is not permitted to mix IPv4 and IPv6 addresses
> within the same message.  In addition, the address family of the fields
> in the message SHOULD be the same as the IP source and destination
> addresses of the packet header.
> 
> ==> would it make sense to say how exactly this is to be verified (i.e.,
> going through encoded-unicast formatting)
> 
> +-----------++-----------------------------------------------------------
> |           ||                            Event
> |           ++-----------+------------+------------+------------+--------
> |Prev State ||Register-  | Could      | Could      | Register-  | RP chan
> |           ||Stop Timer | Register   | Register   | Stop       |
> |           ||expires    | ->True     | ->False    | received   |
> +-----------++-----------+------------+------------+------------+--------
> 
> ==> many tables go beyond the RFC-editor limit 72 lines.  This is one of the
> more important ID-nits, esp. for tables as they could be difficult to
> compress.  Could this be fixed easily?
>                                                                           
>      Subtracting off Register_Probe_Time is a bit unnecessary because it
>      is really small compared to Register_Suppression_Time, but was in
> 
> ==> that could end up as negative as well if you right the timers -- what
> would you do then? :) 
> 
> TU.  The encapsulating DR may perform Path-MTU Discovery to the
> RP to determine the effective MTU of the tunnel.  This smaller MTU takes
> both the outer IP header and the PIM register header overhead into
> account.
> 
> ==> s/Path-MTU/Path MTU/ for consistency?
> ==> s/This smaller MTU takes/The assigned smaller MTU should take/
> (that is, just doing PMTUD does not give you the smaller MTU -- you have to
> subtract the header lengths from that as well...)
> 
> In IPv6, the DR MUST perform Path-MTU discovery, and an ICMP
> Fragmentation Required message MUST be sent by the encapsulating DR if
> 
> ==> s/Fragmentation Required/Packet Too Big/
> ==> you could maybe add informative refs to PMTUD spec here as well -- the
> same would apply to the bit about copying ECN w/ tunnels.
> 
> (sect 4.5.7, sending S,G J/P)
> Finally,
> if it sees the Generation ID of its upstream neighbor change, it knows
> that the upstream neighbor has lost state, and it should refresh the
> state by scheduling a Join(S,G) to be sent almost immediately.
> 
> ==> why is this only discussed here -- this appears to be a more generic
> even, which should triggger sending Joins for *all* groups or S,G pairs
> immediately?
> 
> MRIB.pref(X) and MRIB.metric(X) are the routing preference and routing
> metrics associated with the route to a particular (unicast) destination
> X
> 
> ==> is it clear enough which specific preferences and metrics you're talking
> about .. now that many implementations provide so many of them?
> 
> This specification does not mandate the use of a single mechanism to
> provide routers with the information to perform the group-to-RP mapping.
> Currently three mechanisms are possible, and all three have associated
> problems:
>                                                                           
> Static Configuration
> [...]
> 
> ==> make that "at least three mechanisms", or just include Embedded-RP here,
> with an informational reference.
> 
> 4.9.  Source-Specific Multicast
>                                                                           
> The Source-Specific Multicast (SSM) service model [6] can be implemented
> with a strict subset of the PIM-SM protocol mechanisms.  Both regular IP
> Multicast and SSM semantics can coexist on a single router and both can
> be implemented using the PIM-SM protocol.  A range of multicast
> addresses, currently 232.0.0.0/8 in IPv4, is reserved for SSM
> 
> ==> worth spelling out the equivalent in IPv6 as well?
> 
>  If the packet's length is
>      not an integral number of 16-bit words, the packet is padded with a
>      trailing byte of zero before performing the checksum.
> 
> ==> this was under the IPv6 checksum part.  If this isn't IPv6 specific,
> separate as a paragraph of it's own.
> 
> 11.  Index
> 
> ==> add the IPR and copyright sections.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> editorial
> ---------
> 
> This document is a product of the IETF PIM WG.  Comments should be
> addressed to the authors, or the WG's mailing list at
> [e-mail].
> 
> ==> the m-l is now [e-mail]
> 
> Designated Router (DR):
>       A shared-media LAN like Ethernet may have multiple PIM-SM routers
>       connected to it.  If the LAN has directly connected hosts, then a
>       single one of these routers, the DR, will act on behalf of those
>       hosts with respect to the PIM-SM protocol.
> 
> ==> "If the LAN.." is not accurate, because this happens irrespective of
> whether there are hosts on the LAN or not.  Maybe like:
> 
> "A single one of these routers, the DR, will act on behalf of directly
> connected hosts with respect to the PIM-SM protocol."
> 
> (the same in section 4.3)
> 
> .....
> 
> MRIB  Multicast Routing Information Base.  This is the multicast
>       topology table, which is typically derived from the unicast
>       routing table, or routing protocols such as MBGP that carry
>       multicast-specific topology information.  In PIM-SM, the MRIB is
>       used to decide where to send Join/Prune messages.
> 
> ==> MRIB is used for other purposes as well, mainly, where to expect to
> receive such messages, right?
> 
> In phase one, a multicast receiver expresses its interest in receiving
> traffic destined for a multicast group.  Typically it does this using
> IGMP [5] or MLD [3], but other mechanisms might also serve this purpose.
> One of the receiver's local routers is elected as the Designated Router
> (DR) for that subnet.
> 
> ==> s/is elected/has been elected/ (this happens before anyone expressing
> interest)
> 
>  The (*,G) Join travels
> hop-by-hop towards the RP for the group, and in each router it passes
> through, multicast tree state for group G is instantiated.
> 
> ==> wouldn't "initialized" be better than "instantiated".  Anyway.. works
> for me (this happens a lot elsewhere as well..)
> 
> o Traveling all the way to the RP, and then back down the shared tree
>   may entail the packets traveling a relatively long distance to reach
>   receivers that are close to the sender.  For some applications, this
>   increased latency is undesirable.
> 
> ==> s/latency/latency or bandwidth consumption/ ?
> 
> While the RP is in the process of joining the source-specific tree for
> S, the data packets will continue being encapsulated to the RP.
> 
> ==> s/being/to be/
> 
> To obtain lower latencies, a router on the receiver's LAN, typically the
> DR, may optionally initiate a transfer from the shared tree to a source-
> specific shortest-path tree (SPT).
> 
> ==> s/latencies/latencies or more efficient bandwidth consumption/
> 
> At this point the receiver (or a router upstream of the receiver) will
> be receiving two copies of the data
> 
> ==> s/receiver/receiver's DR/ ? (and/or remove the thing in ()'s)
> 
> Multi-access Transit LANs
>                                                                              
> The overview so far has concerned itself with point-to-point links.
> 
> ==> s/links/transit links/
> 
>                  o Neighbor's Gen ID.
>                                                                              
> ==> consistency: some places say "GenID", some others "Gen ID" or
> "Generation ID".
> 
> The SPTbit is used to indicate whether forwarding is taking place on the
> 
> ==> consistency: some places say "SPTbit", others "SPT bit".  make it
> uniform.
> 
> The primary IP address of a neighbor is the link-local
> address that it uses as the source of its PIM Hello messages.
> 
> ==> as these statements are generic, maybe do a lot of
> s/link-local/(link-local)/ so it applies better to both v4 and v6.
> 
> pim_include(*,G) =
>    { all interfaces I such that:
>      ( ( I_am_DR( I ) AND lost_assert(*,G,I) == FALSE )
>        OR AssertWinner(*,G,I) == me )
>      AND  local_receiver_include(*,G,I) }
> 
> ==> note that nowhere you seem to be defining "AssertWinner(x,x,x)" even
> though that's rather straightforward.
> 
> 4.2.1.  Last-hop switchover to the SPT
>                                                                              
> ==> s/switchover/Switchover/ (similar elsewhere as applicable)
> 
> PIM-Hello messages are sent periodically on each PIM-enabled interface.
> 
> ==> in some places it's "PIM-Hello", in others "PIM Hello".  Make it
> consistent.
> 
> 4.3.4.  Maintaining Secondary Address Lists
>                                                                              
> Communication of a routers interface secondary addresses to its PIM
> neighbors is necessary to provide the neighbors with a mechanism for
> 
> ==> s/routers/router's/
> 
>     if( I_am_RP(G) AND outer.dst == RP(G) ) {
>           bool sentRegisterStop = FALSE;
> 
> ==> remove "bool" -- typically the variables don't have the type in the
> pseudocode in this spec (same applies elsewhere as well)
> 
> message SHOULD be discarded without further processing.  In addition, if
> the Hello message from a neighbor was authenticated using IPsec AH (see
> Section 6.3) then all Join/Prune messages from that neighbor MUST also
> 
> ==> s/AH/Authentication Header (AH)/
> 
>      Join (J)
>           The interface has (*,*,RP) Join state which will cause us to
>           forward packets destined for any group handled by RP from this
>           interface except if there is also (S,G,rpt) prune information
>           (see Section 4.5.4) or the router lost an assert on this
>           interface.
> 
> ==> cause "us" -- what's us? reword..?
> 
> 4.7.  PIM Multicast Border Router Behavior
>                                                                           
> In some cases PIM-SM domains will interconnect with non-PIM domains.
> 
> ==> s/non-PIM/non-PIM multicast/
> 
>      3ffe:b00:c18:1::10 would be computed as 0x3ffe0b00 ^ 0x0c180001 ^
>      0x00000000 ^ 0x00000010, where ^ represents the exclusive-or
>      operation.
> 
> ==> use 2001:db8::/32 in the examples, please.
> 
> The following rules override the normal PIM-SM behavior for a multicast
> address G in the SSM reserved range:
> 
> ==> remove "reserved"
> 
> PIM messages are either unicast (e.g.  Registers and Register-Stop), or
> multicast with TTL 1 to the 
LL-PIM-ROUTERS' group (e.g. Join/Prune,
> Asserts, etc.).  The source address used for unicast messages is a
> domain-wide reachable address; the source address used for multicast
> messages is the link-local address of the interface on which the message
> is being sent.
> 
> ==> s/link-local/(link-local) primary/ ?
> 
> The IPv4 
LL-PIM-ROUTERS' group is à.0.0.13'.  The IPv6 
LL-PIM-
> ROUTERS' group is f02::d'.
>                                                                           
>  0                   1                   2                   3
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |PIM Ver| Type  |   Reserved    |           Checksum            |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> ==> add a prelude before the bit diagram, like "PIM header common to all
> messages is:"
> 
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |          Type = 1             |         Length = 2            |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |         Holdtime             |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> ==> s/Holdtime/Holdtime /
> 
>      OptionTypes 17 thru 65000 are assigned by the IANA.  OptionTypes
>      65001 through 65535 are reserved for Private Use, as defined in
>      [10].
>      Unknown options may be ignored.  The "Holdtime" option MUST be
>      implemented; the "DR Priority" and "Generation ID" options SHOULD
> 
> ==> add a return after "[10]."
> 
> 4.10.5.  Join/Prune Message Format
>                                                                           
> ==> please cut down the format by a few lines; it gets cut into two pages by
> one line already, and it would be very nice if it fit in the same page
> with the preamble of 4.10.5.
> 
>      Values 128 through 250 are designated to be assigned by the IANA
>      based upon IESG Approval, as defined in [10].
> 
> ==> s/assigned/assigned for PIM/ ? (at least so I think it said earlier in
> the spec..)
> 
> Similarly, a Designated
> Router SHOULD NOT accept a Register-Stop packet whose IP source address
> is not a valid RP address for the local domain.
> 
> ==> s/for the local domain/as given by the group-to-RP mapping/
> 
> multicast messages is addressed (one such proposal is [9] ), the anti-
> 
> ==> s/] /]/
> 
> 
> 
> 

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


_______________________________________________
pim mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pim