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

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 7 Oct 2015 15:32:32 +0000

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:

  1.  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.
  2.  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".
  3.  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:

  1.  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.
  2.  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).
  3.  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.

---

From: Stig Venaas <[email-masked]>
Date: Wed, 7 Oct 2015 09:11:40 -0700

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)
<[email-masked]> 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.

---

From: Stig Venaas <[email-masked]>
Date: Mon, 26 Oct 2015 15:31:49 -0700

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)
<[email-masked]> 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: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: AD Review of draft-ietf-pim-explicit-rpf-vector-06
>
> Hi!
>

---

From: Stig Venaas <[email-masked]>
Date: Mon, 26 Oct 2015 15:43:01 -0700

I see an email by Alia to the list on Tue, 26 August 2014, where she writes:

Finally - I really don't see this as being informational.  Either it's
experimental or, since the chairs believe that it has WG consensus, it is
standards track.

That's what I can find so far. Can the authors please help do some
digging, or do you remember? You remember Mike?

Maybe worth listening to the audio of the meeting right before?

Stig

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 27 Oct 2015 15:04:38 +0000

On 10/26/15, 6:43 PM, "Stig Venaas" <[email-masked]> wrote:

Stig:

Hi!

>digging, or do you remember? You remember Mike?

I am usually not too comfortable with the change of status in the middle
of a set of review comments -- mostly because I don't think the WG might
be paying attention (in general, not specific to pim).  [Note: I'm saying
that now as a test. ;-) ]

Mike did send a WGLC message [1] for -06, which already had the "Standards
Track" status in it.  While I didn't see any reply to that, I am ok as
long as the history is somehow reflected in the Shepherd's writeup.

Thanks!

Alvaro.

---

From: Stig Venaas <[email-masked]>
Date: Tue, 27 Oct 2015 09:02:17 -0700

Hi

I agree. We'll do a status update at the upcoming meeting and mention
the status in particular.

Stig

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 27 Oct 2015 16:37:22 +0000

On 10/26/15, 5:56 PM, "Sowmya Krishnaswamy (sowkrish)" <[email-masked]<mailto:[email-masked]>> wrote:

Sowmya:

Hi!

Some comments below..

. . .
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).

Yes, but what are the risks if the vector is not correct/valid?  It is true that it is up to someone else to make sure and the routers won't check, but I need you to talk about the risks in the Security section.

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.

Again, that is what I want to see explained in the Security section.  If there are open issues/risks, then they should be spelled out there.

. . .

Please make this reference Informational.

. . .
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.

You can't upload the new version because the window is closed due to the IETF meeting next week.  The submissions ability will open on Sunday.

In Section 5 (Explicit RPF Vector Attribute TLV Format), I still need you to be specific about the definition of Value.  It still reads that it "could be a valid address".  Please be more specific, maybe "MUST/SHOULD/must be..".  It still begs the question of what "valid" means, so maybe something around it being the address of the upstream router..

It looks like (from the exchange with Stig) that you should go back to a Standards Track status.

Once you update the status and address the security concerns (at least pointing out the risks), I will issue the IETF Last Call.

Thanks!

Alvaro.

________________________________
From: Alvaro Retana (aretana)
Sent: Wednesday, October 7, 2015 8:32 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: AD Review of draft-ietf-pim-explicit-rpf-vector-06

Hi!

Thanks!

Alvaro.

Major:

  1.  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.
  2.  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".
  3.  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:

  1.  References:
     *   "...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.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 27 Oct 2015 22:18:21 +0000

Hi!

You attached the old version.

Alvaro.

Thumb-typed and autocorrected..

> On Oct 27, 2015, at 3:17 PM, Sowmya Krishnaswamy (sowkrish) <[email-masked]> wrote:
> 
> Please review the Security section and let us know if it's ok.

---

From: "Sowmya Krishnaswamy (sowkrish)" <[email-masked]>
Date: Wed, 28 Oct 2015 18:17:49 +0000

Attaching the latest XML.
________________________________________
From: Alvaro Retana (aretana)
Sent: Tuesday, October 27, 2015 3:18 PM
To: Sowmya Krishnaswamy (sowkrish)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: AD Review of draft-ietf-pim-explicit-rpf-vector-06

Hi!

Alvaro.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 28 Oct 2015 19:20:29 +0000

Sowmya:

Hi!

Sorry for being so picky, but the Security section is not there yet.

The new text you added is this:

   ...There is the risk of a malicious node injecting an
   incorrect Explicit RPF vector stack.  Since the draft does not have a
   feedback mechanism to the end nodes that are injecting the Explicit
   RPF vector as to whether the injected path was used or an alternate
   path was used due to conflict resolution on an upstream node, it is
   upto the mechanisms that produced the Explicit RPF vector to ensure
   that the the PIM tree is built correctly.

If I was the security AD, I would then ask you to build in that feedback
mechanism. :-(

The risks that I see are:
- injecting a incorrect stack (as you mentioned above),
- topology changes resulting in nodes that don't support this in the path
- changes in features/support at the nodes (maybe as a result of a crash..)

...there might be others.  Note that 2 of those risks may still occur even
if the stack was correct -- but not having that feedback mechanism may
results in issues (lost traffic, loops, etc.) a long time after the stacks
were first injected.

Because the programming of the network is external, what about
authentication and authorization?

Maybe I'm becoming too paranoid, but those are the types of things I'm
expecting in the Security considerations.  Maybe some text like this:

"The creation of the Explicit RPF Vector list is outside the scope of this
document.  It is then expected that the mechanisms used create a correct
list: one that describes a path for the Join message to be propagated
without looping, that considers only nodes that support the mechanism
defined in this document, etc..  [IOW, define what "correct" is.]  The
network administrator should take special care in strictly verifying the
authentication and authorization of and potential protocol/mechanism used
to program the network.  Given that even if the path is correct, the
network topology (for example) can change over time, it is recommended
that the administrator strictly monitor the network in order to react to
any events that may require the instantiation of a new list.."

Please include something like that and upload the new version (after
Sunday) and then I'll start the IETF Last Call.

Thanks!

Alvaro.