Re: [MBONED] Benjamin Kaduk's Discuss on draft-ietf-mboned-ieee802-mcast-problems-11: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 09 January 2020 16:48 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: mboned@ietfa.amsl.com
Delivered-To: mboned@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E2A120019; Thu, 9 Jan 2020 08:48:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 lAXTp2_yHBqb; Thu, 9 Jan 2020 08:48:40 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 337CC12001A; Thu, 9 Jan 2020 08:48:40 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 009GmZ5J019422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 9 Jan 2020 11:48:37 -0500
Date: Thu, 9 Jan 2020 08:48:34 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Alvaro Retana <aretana.ietf@gmail.com>
Cc: The IESG <iesg@ietf.org>, mboned@ietf.org, mboned-chairs@ietf.org, draft-ietf-mboned-ieee802-mcast-problems@ietf.org
Message-ID: <20200109164834.GE57294@kduck.mit.edu>
References: <157852198268.22611.624000399578080107.idtracker@ietfa.amsl.com> <CAMMESsw0=kzd9zV9Z54Rqg7kvPxu=nTAqqkmM+B8jiXu=8k9sw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAMMESsw0=kzd9zV9Z54Rqg7kvPxu=nTAqqkmM+B8jiXu=8k9sw@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/-CdcVoEHBP2w230KajeY3VsVGpY>
Subject: Re: [MBONED] Benjamin Kaduk's Discuss on draft-ietf-mboned-ieee802-mcast-problems-11: (with DISCUSS and COMMENT)
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mboned/>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2020 16:48:42 -0000

On Thu, Jan 09, 2020 at 05:51:13AM -0800, Alvaro Retana wrote:
> On January 8, 2020 at 5:20:00 PM, Benjamin Kaduk via Datatracker wrote:
> 
> Hi!
> 
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > Section 9 says that "[RFC4601], for instance, mandates the use of IPsec
> > to ensure authentication of the link-local messages in the Protocol
> > Independent Multicast - Sparse Mode (PIM-SM) routing protocol" but I
> > could not find where such use of IPsec was mandated. (I do recognize
> > that a similar statement appears almost verbatim in RFC 5796, but RFC
> > 5796 seems focused on extending PIM-SM to support ESP in additon to the
> > AH usage that was the main focus of the RFC 4601 descriptions, and does
> > not help clarify the RFC 4601 requirements for me.) The closest I found
> > was in Section 6.3.1 of RFC 4601: "The network administrator defines an
> > SA and SPI that are to be used to authenticate all link-local PIM
> > protocol messages (Hello, Join/Prune, and Assert) on each link in a PIM
> > domain" but I do not think that applies to all usage of PIM-SM. Am I
> > missing something obvious?
> 
> It looks like everyone (including me) missed the nit that rfc4601 has
> been Obsoleted by rfc7761.  One of the changes between the two is that
> rfc7761 removed the requirement for authentication using IPSec "due to
> lack of sufficient implementation and deployment experience".

I think Roman did pick up on the obsoletion, but it was buried in the nits
at the end of his ballot position.

As you rightly note, this does supersede my specific objection to this
document (though I still would like to know which part of RFC 4601 made
this requirement, if only to know whether or not to file an erratum on
5796).

> This is what rfc7761 says about authentication:
> 
>    6.3.  Authentication
> 
>       This document refers to RFC 5796 [8], which specifies mechanisms to
>       authenticate PIM-SM link-local messages using the IPsec Encapsulating
>       Security Payload (ESP) or (optionally) the Authentication Header
>       (AH).  It also points out that non-link-local PIM-SM messages (i.e.,
>       Register and Register-Stop messages) can be secured by a normal
>       unicast IPsec Security Association (SA) between two communicants.

And that seems like a good treatment of the situation.

Thanks,

Ben