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

"Sowmya Krishnaswamy (sowkrish)" <sowkrish@cisco.com> Tue, 27 October 2015 19:18 UTC

Return-Path: <sowkrish@cisco.com>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474BF1ACE70; Tue, 27 Oct 2015 12:18:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5kzfymKUaQ6; Tue, 27 Oct 2015 12:17:58 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E6421ACE67; Tue, 27 Oct 2015 12:17:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=52779; q=dns/txt; s=iport; t=1445973478; x=1447183078; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Q8l9HLOEkViM1cDM2ro41Z/hxKpTYvaH0MLqLAUSleU=; b=IXDawYB5nNiI8mEA3EGHr6FE0KNCdakpu0UDShZYt6sozL2QiVsCphj+ IpdZAGk8uukf8rWpVJXqcrgRtV8pbeeWScXVrtIu5TDUANWwRj7SW/FJe KfTW3E/tbbYFS8ORHsyWYbuku4Mq6UWe0v+Dqy7xa5IB0tsSENGCHiJtq s=;
X-Files: draft-ietf-pim-explicit-rpf-vector-07.rtf : 16165
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CzBABEzS9W/51dJa1eEwEBglRNVG8Grn+QBA6BWiGCG4NeAoFEOBQBAQEBAQEBgQqEMgEBAQQaAQweKQsQAgEIEQQBAQoXBwcCDRIRFAkIAgQBDQUOiA0DEg21QotlDYRBAQEBAQEBAQEBAQEBAQEBAQEBAQEBDwmGd4N4gQaCUIFaCwYBNgkIBQUGAQaEKAEEixyHMRaDVQGCUIJLgnCCX0OBdoFZFTODd4QbgxmGFoEBg1+DbwEfAUOCDIF4coQmAQcXBxyBBgEBAQ
X-IronPort-AV: E=Sophos;i="5.20,206,1444694400"; d="rtf'212?scan'212,208,217,212";a="201143684"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP; 27 Oct 2015 19:17:56 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t9RJHu9t024240 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 27 Oct 2015 19:17:56 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 27 Oct 2015 14:17:31 -0500
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.000; Tue, 27 Oct 2015 14:17:31 -0500
From: "Sowmya Krishnaswamy (sowkrish)" <sowkrish@cisco.com>
To: "Alvaro Retana (aretana)" <aretana@cisco.com>, "draft-ietf-pim-explicit-rpf-vector@ietf.org" <draft-ietf-pim-explicit-rpf-vector@ietf.org>
Thread-Topic: AD Review of draft-ietf-pim-explicit-rpf-vector-06
Thread-Index: AQHRARViSI1V4VTqsU2ooCLfzKJFqJ5+ZhfogAFUGoCAABpshg==
Date: Tue, 27 Oct 2015 19:17:31 +0000
Message-ID: <1448310480492.34744@cisco.com>
References: <D239907B.D7D75%aretana@cisco.com> <1445897287704.60786@cisco.com>,<D255048B.E6306%aretana@cisco.com>
In-Reply-To: <D255048B.E6306%aretana@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.154.212.174]
Content-Type: multipart/mixed; boundary="_004_144831048049234744ciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/pim/4s6iycN47IEIyvsMwKitxEG9lrQ>
X-Mailman-Approved-At: Mon, 02 Nov 2015 14:10:02 -0800
Cc: "mmcbride7@gmail.com" <mmcbride7@gmail.com>, "pim-chairs@ietf.org" <pim-chairs@ietf.org>, "pim@ietf.org" <pim@ietf.org>
Subject: Re: [pim] AD Review of draft-ietf-pim-explicit-rpf-vector-06
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Oct 2015 19:18:04 -0000

Hi Alvaro,


Thanks for the review comments. We have updated the draft to address the comments.


1. Pointed out the risks in the Security considerations section,

2. Changed the draft to standards track,

3. Updated Section 5 to clarify value field.


Please review the Security section and let us know if it's ok.


Best Regards,

Sowmya


________________________________
From: Alvaro Retana (aretana)
Sent: Tuesday, October 27, 2015 9:37 AM
To: Sowmya Krishnaswamy (sowkrish); draft-ietf-pim-explicit-rpf-vector@ietf.org
Cc: mmcbride7@gmail.com; pim-chairs@ietf.org; pim@ietf.org
Subject: Re: AD Review of draft-ietf-pim-explicit-rpf-vector-06

On 10/26/15, 5:56 PM, "Sowmya Krishnaswamy (sowkrish)" <sowkrish@cisco.com<mailto:sowkrish@cisco.com>> 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.


. . .
5. We have updated references to ietf-rtgwg-mofrr to rfc7431.

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.

Please let us know if the changes look ok.

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: draft-ietf-pim-explicit-rpf-vector@ietf.org<mailto:draft-ietf-pim-explicit-rpf-vector@ietf.org>
Cc: mmcbride7@gmail.com<mailto:mmcbride7@gmail.com>; pim-chairs@ietf.org<mailto:pim-chairs@ietf.org>; pim@ietf.org<mailto:pim@ietf.org>
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:

  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.