Re: [pim] AD Review of draft-ietf-pim-explicit-rpf-vector-06

[Stig Venaas <[e-mail]>]

Hi

I hope the authors can try to address these issues and submit a new
draft before the upcoming submission deadline. I'm pretty sure we had
some discussion about the draft being standards track, but I can't
remember right now. Does anyone? Mike, as shepherd, do you remember
and can you update the writeup?

If no one remembers, I'll try to search for it myself, including
checking meeting minutes and recordings if necessary.

Stig


On Wed, Oct 7, 2015 at 8:32 AM, Alvaro Retana (aretana)
<[e-mail]> wrote:
> Hi!
>
> I just finished reading this document.  I have a couple of Mayor items that
> should be easy to resolve and a some Minor ones.
>
> My main concern with this document is around the validation of the
> correctness of the information.  While  there is no specified mechanism to
> validate the correctness of the vectors, the Security Considerations section
> says that "the Explicit RPF Vector list should be subject to a policy to
> validate the list consists of a valid path before its used by a receiver to
> build a multicast tree"..so there seems to be a contradiction between that
> is expected and what is being specified.
>
> Knowing that we're in a world where external agents
> (controllers/administrators/etc.) somehow "know everything", I am ok with
> the assumption that they came up with a valid path ("How the Explicit RPF
> Vector list is determined is outside the scope of this document.") as long
> as potential risks are explicitly outlined, and some of the basics are
> clarified.
>
> I expect at least some discussions and an update to the document.  When that
> is done I'll start the IETF Last Call and move this document forward.
>
> Thanks!
>
> Alvaro.
>
>
>
> Major:
>
> Indented Status.  The datatracker page and the Shepherd Writeup both mention
> that the document should be "Informational because its useful primarily in
> specific scenarios and it's what the WG agreed upon", but the header says
> "Standards Track".  It looks like the status on the document changed in –05,
> which came out after the current Shepherd Writeup, but it's not clear from
> the mailing list if that was discussed (and the datatracket/writeup are just
> outdated) or if the document needs to be updated.
> Correctness and Validation.  As identified in Section 3. (Motivation), there
> are no "new mechanism in PIM to validate the correctness of the RPF
> vectors".
>
> New?  Are there existing mechanisms?
> Section 10. (Unsupported Explicit Vector Handling)
>
> The document expects "that the administrator computes the path to include
> routers that support explcit (sp) vector and check that the state is created
> correctly on each router along the path."  That is a very nice expectation,
> but what happens if something changes?
> What about the case where a mixed set of vectors exists, and the Explicit
> Vectors are the unsupported ones?
> Do changing conditions in the network with the potential of nodes not
> supporting the vectors, create a (security or operational) vulnerability?
>
> Section 13. (Security Considerations) does say that "the Explicit RPF Vector
> list should be subject to a policy to validate the list consists of a valid
> path before its used by a receiver to build a multicast tree."  This is
> interesting specially because there's text that says that "how the Explicit
> RPF Vector list is determined is outside the scope of this document."  IOW,
> the document is not saying how to build the information, but it does say
> that it has to be validated.  I have several questions about this — it would
> go a long way if you could be more explicit.  I don't think we need to
> include all the answers or be too specific, but a little more clarity might
> help with any concerns from the SecDir or Security ADs.
>
> What do you mean by a "policy"?  Are you hinting at a gating function to
> either accept or not a vector list?  If so, how would/could that be
> coordinated across multiple nodes?
> What is a "valid path"?  I assume that means a path made of "valid
> addresses", but is the validity determined just by a reachable address?  Or
> should the validator be looking for the addresses to be reachable in a
> specific order (path)?  Or ??
> BTW, in 11. (Explicit RPF Vector Attribute TLV Format) the address is
> defined as "Value: … This could be a valid primary or secondary address."
> "Could be", meaning it can be just that, or that it could be anything?
> Maybe just don't be so specific (primary or secondary) and leave it at
> "valid address".
>
> Section 11. (Explicit RPF Vector Attribute TLV Format)
>
> "Length:  Length depending on the Address Family of the Encoded-Unicast
> address."  [I know this is the same text as in rfc5496.]  The description
> sounds like I need to know what type of address I have in the next field to
> determine if the length is correct..but there is no explicit indication of
> which AF is being used.  In fact, nowhere in the document is there a mention
> that the possible AFs are IPv4/IPv6 — it would be very nice if that was
> explicitly mentioned.  I don't think we need to change the encoding at thins
> point, but knowing that (today) there are only two expected lengths would
> help with determining validity.
>
>
> Minor:
>
> References:
>
> The reference to I-D.ietf-rtgwg-mofrr is outdated (now rfc7431).  I also
> think we could make it an Informational Reference.
> Change the reference to rfc4601 to I-D.ietf-pim-rfc4601bis.  Please take a
> look at the updated Security Considerations (in draft-ietf-pim-rfc4601bis
> wrt rfc4601) to make sure that the reference still works.
>
> It looks like Section 5. (Explicit RPF Vector Attribute) is superfluous as
> the details of the TLV are defined elsewhere.  In fact, I would move Section
> 11 to this position (just a nit).
> Section 7. (Conflicting RPF Vectors)
>
> "…the content of the RPF Vectors MUST be compared ([RFC5384])."  It seems
> like this reference is out of place as rfc5384 was already positioned as not
> addressing the specific problem of mixed RPF vectors.