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

[Pekka Savola <[e-mail]>]

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