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

[Stig Venaas <[e-mail]>]

Hi

I'm fairly sure we discussed that the draft should be standards track
in some meeting, and I wonder if it was one of the things Alia brought
up when reviewing it?

I haven't found anything in the written minutes though. Don't any of
you authors remember? Any old emails you can find?

In the worst case someone will have to go and listen to the audio to
find out. We should not just change it back to Informational. I'm
pretty sure we must have changed to PS because we agreed to make the
change.

Stig


On Mon, Oct 26, 2015 at 2:56 PM, Sowmya Krishnaswamy (sowkrish)
<[e-mail]> wrote:
> Hi Alvaro,
>
>
> Thanks for the detailed review comments. We have made corrections to address
> the review comments.
>
>
> Crux of the changes are as follows:
>
>
> 1. Updated the Status of the draft to Informational.
> 2. Stressed the fact that it is upto the mechanism that produce the explicit
> RPF vector to ensure that they are correct in Section 3 (Motivation) and
> again in the Section 11 (Security considerations).
> 3. Your comments about section 10 are valid, but at this point without
> making additional protocol changes to include a feedback mechanism to the
> end-nodes that are injecting the explicit RPF vector there is no clean way
> to address the security concern. We would like to limit the scope of this
> draft by clearly stating that the the controllers / mechanisms that inject
> the explicit rpf vector needs to check that the tree is built along the
> intended path.
> 4. We have removed Section 5 and updated it with the contents of Section 11
> (Explicit RPF Vector TLV Format). We have indicated that we support IPv4 and
> IPv6 address family.
> 5. We have updated references to ietf-rtgwg-mofrr to rfc7431.
> 6. Updated reference to rfc4601 to I-D.ietf-pim-rfc4601bis.
> 7. Regarding logic to handle conflicting attributes we are using the logic
> from RFC5384. The RPF vector from the neighbor with the lowest IP address is
> accepted.
> 8. We are not able to upload version 7 of the draft, it might be because it
> was sent for AD review, hence I am sending the updated draft as an
> attachment.
>
> Please let us know if the changes look ok.
>
> Best Regards
> Sowmya
>
> ________________________________
> From: Alvaro Retana (aretana)
> Sent: Wednesday, October 7, 2015 8:32 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: AD Review of draft-ietf-pim-explicit-rpf-vector-06
>
> 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.