Subject: [pim] Stephen Farrell's No Objection on draft-ietf-pim-hierarchicaljoinattr-07: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 19 Apr 2016 03:12:26 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-pim-hierarchicaljoinattr-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pim-hierarchicaljoinattr/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Two related but minor points:

- section 5, last para: can a router always know for sure that
everyone who'll get a message sent on an interface knows about
this new encoding? If not, the "MUST NOT" here is incorrect.
One could implement a MUST NOT that said to only send this to
routers who'd expressed the hello option, but saying that the
MUST NOT applies to everyone accessible from the sender's
interface is arguably not implementable. The real-world result
would be the same though, even if one's code would better match
the latter way of describing the MUST NOT, so not that big a
deal.

- section 6: If a router had a bug that caused it to crash (or
do bad stuff) when it unexpectedly receives a message with this
new encoding, then if I faked a message with the new hello
option to a peer of that router, I might be able to cause
someone else to crash the victim/target.  There are probably
other bad things I can do if I can fake a hello like that, but
this is perhaps a new one. I'm not claiming that's worth a
mention though, unless the authors/chairs/shepherd want to add
it.

---

From: Stig Venaas <[email-masked]>
Date: Tue, 19 Apr 2016 10:17:44 -0700

Hi Stephen

Please see my comments inline.

> https://datatracker.ietf.org/doc/draft-ietf-pim-hierarchicaljoinattr/

I think I know what you mean, but I don't think the draft states quite
what you write here. Note that the PIM message is sent to the
all-pim-routers multicast address, so in theory it should reach all PIM
routers that are present on the link.

The draft states:

   A PIM router MUST NOT send a Join/Prune message with Join/Prune
   attributes encoded in the Upstream Neighbor Address or any of the
   group addresses out any interface on which there is a PIM neighbor
   that has not included this option in its Hellos.

It doesn't strictly talk about "everyone accessible", but only the routers
that are this particular PIM router's PIM neighbors. That they are PIM
neighbors means that this router must have received PIM Hello messages
from them, as that is how you establish the neighborship. The meaning of
the draft then is that if at least one of these neighbors do not support the
new mechanism (the hello option was not present in the last hello from the
neighbor), then the router MUST NOT send a message using the new
mechanism.

In theory there could be routers on the link receiving the message that we
did not receive hello messages from. In that case we may still send
messages with the new mechanism and those routers would not be able
to parse the message, but this does not violate the specification since they
are not PIM neighbors.

> mention though, unless the authors/chairs/shepherd want to add

Yes, I'm not sure if worth mentioning since this is true for any new
encoding. The parsing does get more complicated though, so it
increases the chance that an implementation got it wrong.

Perhaps it is worth pointing out that routers not supporting this new
encoding would ignore the encoded data. Hence no direct harm is
caused if an attacker (or a router by accident) sends a message with
the new encoding, the worst that can happen is that some data gets
ignored.

It could potentially be an issue (not necessarily a security issue) if
a router accidentally sends such a message and some routers
ignore the data though. Hence we only use it when we believe all
the routers support it. But as I commented on the other issue
above, there could be routers receiving it that we are unaware of.
But during normal correct operations, this would only happen if a
router interface just came up and we have not yet received a hello.
Since we send periodic J/P messages and have soft state, this
should at most cause a temporary problem. This is more an
operational issue than a security issue I would think. Note that we
generally use PIM hello options to signal capabilities and we have
the same issues in those cases as well.

Stig