Subject: [pim] PIM and IPsec experience

From: Stig Venaas <[email-masked]>
Date: Mon, 09 Mar 2015 17:10:14 -0700

Hi

As part of making RFC 4601 an Internet Standard we would like to know to
what extent there is experience with AH interoperability. Has anyone
conducted tests or are aware of deployments with multiple
implementations? What about ESP?

It would also be interesting to know about deployments using IPsec,
even if just a single implementation is involved. No need to name
particular deployments, but it would be nice to get some idea how
common it is.

Stig

---

From: Alia Atlas <[email-masked]>
Date: Mon, 9 Mar 2015 20:38:07 -0400

To be clear, this needs to be figured out to progress 4601bis.  There are
three possibilities that I see:

a) AH has interoperable implementations and deployments and is kept in
4601bis - with ESP updating it.
b) AH doesn't have interoperable implementations or enough deployment and
is removed from 4601bis - and
a downref is put to RFC5796 saying that ESP is required.
c) ESP have interoperable implementations and enough deployment experience.
 4601bis is updated to
include RFC5796 or we have a quick 5796bis that 4601bis can refer to and
both go to Internet Standard.

Which of these options to do (or to come up with others) is up the working
group and chairs.

Alia

On Mon, Mar 9, 2015 at 8:10 PM, Stig Venaas <[email-masked]> wrote:

> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim
>

---

From: William Atwood <[email-masked]>
Date: Tue, 10 Mar 2015 12:15:33 -0400

Stig,

At Concordia, as part of the work supporting the development specified
in RFC 5796, we did a series of tests.

1) Two and three "soft" routers (Linux boxes running XORP) for the "same
key for everyone" and "separate keys for each sender" cases.

2) Two and three Cisco 2811 routers for the same two cases, except that
we could not run the "three-router, separate keys case for each sender"
case due to a limitation in the Cisco command line interface for manual
keying.

3) Inter-operation of a XORP router and a Cisco 2811, for both the
"same-key" and the "separate key" cases, with one XORP router and one
Cisco router.  (The "three-router, separate keys" case was not tried,
for the reasons given above.)

4) Inter-operation of a XORP router and a Cisco 2911.

AH was used in all the tests.

Since the establishment of the IPsec parameters is _completely_
independent of the PIM-SM code, I expect that it would not be difficult
to demonstrate inter-operation with ESP.  I would be willing to provide
the manpower to do this.

The above establishes the existence of two independent inter-operating
implementations.  If I can find someone to loan me a suitable router
from another company (with IPsec enabled), I expect that it would not be
hard to demonstrate inter-operation with a third implementation, for
both AH and ESP.  (I would be willing to provide the manpower to do this.)

  Bill

-- 
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     email:[email-masked]
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 10 Mar 2015 16:23:11 +0000

Lab testing can provide data on interoperability, but what about deployment experiences?

> -----Original Message-----
> From: William Atwood [mailto:[email-masked]]
> Sent: Tuesday, March 10, 2015 12:16 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [pim] PIM and IPsec experience
> 
> Stig,
>

---

From: Brian Haberman <[email-masked]>
Date: Tue, 10 Mar 2015 12:31:16 -0400

All,

> Lab testing can provide data on interoperability, but what about deployment experiences?

Deployment experience is key.  RFC 6410 describes the four conditions
for advancing a specification to Internet Standard.

   (1) There are at least two independent interoperating implementations
       with widespread deployment and successful operational experience.

   (2) There are no errata against the specification that would cause a
       new implementation to fail to interoperate with deployed ones.

   (3) There are no unused features in the specification that greatly
       increase implementation complexity.

   (4) If the technology required to implement the specification
       requires patented or otherwise controlled technology, then the
       set of implementations must demonstrate at least two independent,
       separate and successful uses of the licensing process.

Point (1) needs to be documented and that includes deployment experience.

Regards,
Brian

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 10 Mar 2015 11:59:45 -0700

If we assume very little deployment epxerience... where would that
leave us wrt. to AH vs. ESP vs how to move forward on the spec side ?

Cheers
    Toerless

-- 
---
Toerless Eckert, [email-masked]

---

From: Alia Atlas <[email-masked]>
Date: Tue, 10 Mar 2015 15:04:13 -0400

> leave us wrt. to AH vs. ESP vs how to move forward on the spec side ?

We are checking to see how the RFC Editor can handle Updates for 4601bis.
It would be useful in 4601bis to have Informational references to the
various RFCs
that update 4601 and help set them in context for a future reader.

Alia

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 11 Mar 2015 06:37:30 -0700

Sure, such a list sounds iuseful. But that does not answer my question.

---

From: Brian Haberman <[email-masked]>
Date: Wed, 11 Mar 2015 10:10:55 -0400

Hi Toerless,

> Sure, such a list sounds iuseful. But that does not answer my question.

Let me take a crack at it.

>>> leave us wrt. to AH vs. ESP vs how to move forward on the spec side ?

The rules on advancing a specification to IS are rather clear on this.
If a feature does not have wide implementation and deployment
experience, it is pulled out of the specification.

In the case of 4601bis, I would suspect that section 6.3 would be taken
out.  If so, it could be replaced with an informative reference to RFC 5796.

The other RFCs that update 4601 would need to be examined to see how
they impact the spec as well.

Regards,
Brian

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 11 Mar 2015 07:36:15 -0700

Some thoughts on the crypto section:

I think the pragmatic, non-crypto based security mechanisms of which
a good set is mentioned in rfc4609 are a lot more deployed than
ESP/AH based security for PIM. So i do not understand why 4601bis gives
so much room to the crypto mechanism only and does not include a larger
set of non-cryptographic mechanisms.

I know of two implementations of PIM with IPsec. One supports AH/ESP
and IMHO that IPsec function is not widely deployed with that IPsec for
PIM configured. The other implementation only performans AH for PIM Hello,
so its non-interoperable with the first implementation. This too makes
me think the IPsec fearue is not widely deployed, and if it is there
does not seem to be a lot of need for interoperability.

AH or ESP headers are known to break IGMP snooping  (trying to determine
which ports are router ports). And even more so PIM snooping. If the IETF
wants to push security into protocols without hard deployment needs,
then could this please be done in a way that interoperates, even if it is
with stuff that we hate but know is widely deployed ? "Implementations
using AH or ESP authentication for PIM packets MUST have a configuration
option to ALO send unauthenticated PIM Hellos or unauthenticated ALL PIM
messaged on the LAN to support existing IGMP/MLD/PIM snooping in LANs".

IETF/RFCs do not have PICs so it really does not matter what 4601bis
says about IPsec as long as it's not a MUST which it currently isn't
A separate RFC for security with PIM with only MUSTs would be a lot
more useful for customers given how most vendor product docs only
list RFCs anyhow (ok, support 4601... no idea what amount of security).

Cheers
    Toerless