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

William Atwood <> Thu, 09 January 2020 19:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E4BA1201DC; Thu, 9 Jan 2020 11:37:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.534
X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hpZNUXczcRTy; Thu, 9 Jan 2020 11:37:23 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C3EB2120144; Thu, 9 Jan 2020 11:37:23 -0800 (PST)
Received: from [] ( [] port 16021) by (envelope-from (8.13.7/8.13.7) with ESMTP id 009JbEma009727; Thu, 9 Jan 2020 14:37:15 -0500
To: Benjamin Kaduk <>, Alvaro Retana <>
Cc:,, The IESG <>,
References: <> <> <>
From: William Atwood <>
Autocrypt:; prefer-encrypt=mutual; keydata= mQGiBEmjdrMRBADawl3I6QQW9RTYKHQk0tMhjbbgi7clCKZzmgTOOHKYDil9J68+xyTdXlBT ud5crBx2kYf334Uf5fOBNBh6Z/3kUr2qkvVHXAp+yox81wao8pBwQ5wcnhPmnGhpsapCMeBA 3deiCQfvd9AVygrNZOJvW526PIHiNvob2pDT4ef0iwCgroVoHugkt+84Ly3jL9lcFFmqW38D /2exybJrzefDFGHExaQinYRwIovHhdilirh3k6BcRaS6xWUbWsra+w0OSQWCt+Ooaj6Zmeio 13U5lybjD4M0Se7TI0AW6JJsHot3x69/2Uq2OWb1cddezafZ4+vlNybC5LZ+tynTVt2RB7lE Yy34W9kTWIHsaFOLUjDaZW+ScpKoA/9yXM3FY7hUTBEgP5+CUyX4zYsnxtmeurhVi4D3Ri1e TRQhE/WxaVsxxqJuFNx/rzOPwnekWa06cb4mKYHJ6HJ/q1hjSCOvhlSUgLwQ6XiqYW/dulfL ulq6d9w01gApWPNdaimLOnZi/Of52YO7RZroSNPBwC71hOxzQCzeHZLgaLQxSm9obiBXaWxs aWFtIEF0d29vZCA8d2lsbGlhbS5hdHdvb2RAY29uY29yZGlhLmNhPohjBBMRAgAjAhsjBgsJ CAcDAgQVAggDBBYCAwECHgECF4AFAlC5EYcCGQEACgkQV5o4IdDwBVhFdACePdBrMqD3jC9V 53DbmgWkIR5oHVAAn1HPsfaMXQsIyim9d2wpwQunGDcXuQINBEmjdrMQCACDziZLszCCtC0i 195vC7UlKnKEE7rLKP+tzpJuPb6EW27xBtJ2cr6RXZQ84rrHvgczmhaht7kUPyyAFVUG2pbK 9vOBPcurdimtz4cc5FJ6v2wi9NoNaxag8MY2WYYzH7Fs4Bh7ZK7B6pR/lYVNltu8vxT7MO4p k+jjDaKkYU4VlN9dWrwTapmBbYafdOHhxnvxYrr3TsLdpYbGiucDwLtWGgd7+jx9LUT9tStg RgSYpwULZbQWHjSGRAXHtOzsk01TcTUP+rzbqteQ+3n867848rnJxoOWdOF73TR32dif0osf DAr4EuHHSkRI8a7me8zcVVZGhjQsp6JGsnhKO0AfAAMFB/9Cym72Z7nNw4ewqhVAVPal+tQG zkyh1S8vTEo6GdOK7eapc1OaSK7YCAS6UmFVTgoAjRBUPA5L7aLorSUXwzjZ7X26Pn2ywlnI c8+7AlbeGnggEg1h95QQTly+xU3ZEiBF0LhhyAwpISqGiz7zq44w2pqAxnAiKNX2xZxjHdZ+ yDMxT86Yj/U7K6ITv4/GwygS7bMt9+wXYRzvr9gHr5jKMEsTeIJHi5UNWLYfpfmhyF6sZ3KT qHFVAZ6yu2xDuAEhnIWaOUC2+Z9XHLMvgSrxIleqkKJiWZbAc9C1F/iV+DeQ7rNPNg9pN2Kr imkVfjdMTCwORUeeGprBurp3wCy/iEkEGBECAAkFAkmjdrMCGwwACgkQV5o4IdDwBVgd9gCf YD8t+Q9rphTC4HpOX9lHYEIIko8An2V2hchJax+LOGzSQOXOj8OgK3g3
Organization: Concordia University, Montreal
Message-ID: <>
Date: Thu, 9 Jan 2020 14:37:14 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.58 on at 2020-01-09 14:37:16 EST
Archived-At: <>
Subject: Re: [MBONED] Benjamin Kaduk's Discuss on draft-ietf-mboned-ieee802-mcast-problems-11: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mail List for the Mboned Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Jan 2020 19:37:26 -0000

Speaking as one of the authors of RFC 5796.

RFC 4601 specified AH, as the way to do "security", if security was
being done.

It was clear (at least to me) that current guidance from the security
community, at the time RFC 5796 was written, was to prefer ESP over AH.
 Since this would permit encryption of the content as well as
authentication of the sender, we decided to recommend ESP as the
required approach, and permit AH as an option.

  Bill Atwood

On 2020-01-09 11:48 a.m., Benjamin Kaduk wrote:
> 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!
>>> ----------------------------------------------------------------------
>>> ----------------------------------------------------------------------
>>> 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
> _______________________________________________
> MBONED mailing list

Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185
1455 de Maisonneuve Blvd. West
Montreal, Quebec Canada H3G 1M8