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

"Sowmya Krishnaswamy (sowkrish)" <sowkrish@cisco.com> Mon, 26 October 2015 21:57 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 51C371A1C06; Mon, 26 Oct 2015 14:57:07 -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 RQk-0wNv7xcF; Mon, 26 Oct 2015 14:57:02 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 035821A1BFE; Mon, 26 Oct 2015 14:57:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43814; q=dns/txt; s=iport; t=1445896622; x=1447106222; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Ud+mbJBcNYg/pL4VltuAGE+QKKpu4TR40hx85ITP0pM=; b=aeORpchmCjzVDH0TVv5uAkq+Hkkc227DGKZQe6U/0rN14Y8g5Qm3zQGy +rC8MmBaEP2aN7go2d8WjtNMSeVw49a+Ptx/icYYYp0dyMz89kK1RB4gb 6FRwkqc8DXYOa9Z48LKZflqlryzZQQZaHHqKFg+UwToMClSRXVedJNn8S 4=;
X-Files: draft-ietf-pim-explicit-rpf-vector-07.xml : 15051
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ArAwAToS5W/5ldJa1egmlNgUMGrjuQAw6BWoYdAoE4OBQBAQEBAQEBgQqEMgEBAQQaDUcLEAIBCBEEAQEKJQINEhEdCAIEAQ0FDogNAxK2dIo9DYRFAQEBAQEBAQEBAQEBAQEBAQEBAQEBDwmGd4N4gQaCUIFaCwYBNhYFBwaEKAEEixuHMRaDVAGCUIU7gyGBdYFZhD+EG4ksgQGDX4NvAR8BQ4IMgXdyhVABBxcHHIEGAQEB
X-IronPort-AV: E=Sophos;i="5.20,201,1444694400"; d="xml'217?scan'217,208,217";a="201416801"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP; 26 Oct 2015 21:57:00 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t9QLuxtY003140 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 26 Oct 2015 21:56:59 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 26 Oct 2015 16:56:35 -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; Mon, 26 Oct 2015 16:56:35 -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+Zhfo
Date: Mon, 26 Oct 2015 21:56:35 +0000
Message-ID: <1445897287704.60786@cisco.com>
References: <D239907B.D7D75%aretana@cisco.com>
In-Reply-To: <D239907B.D7D75%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.179]
Content-Type: multipart/mixed; boundary="_004_144589728770460786ciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/pim/hqWBfKnoOFDYPY11qb1llDfQG5k>
X-Mailman-Approved-At: Mon, 02 Nov 2015 14:09:44 -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: Mon, 26 Oct 2015 21:57:07 -0000

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