Subject: Re: [RPSEC] Multicast Routing System Security....

From: Thomas Hardjono <[email-masked]>
Date: Fri, 12 Apr 2002 15:16:49 -0400

I think RPSEC would be effective if it could focus on (a) addressing
the unicast routing protocols for the moment, and (b) to get vendors to
implement it. (I realize the current RPSEC charter doesn't say anything
about vendors or implementations, but I think (b) should be the
unwritten end-goal).

Also, if you can solve needs related to unicast routing security,
it will also help with some multicast routing protocols
For example, a group-authentication or source-authentication method for
broadcast of a message in a unicast flood/prune protocol may be useful
for a multicast routing protocol that uses a special-multicast-routers group.

W.R.T. multicast routing and MSEC.  Multicast routing security
was part of the SMuG end-goal.  The folks at SMuG quickly realized
thatin a multicast routing protocol (e.g. PIM-SM) that employed IP multicast
itself to disseminate routing-related messages, some form of
cryptographic MAC or signing would be needed.  This, in turn, would
need functions for key management, namely group-key management and group-SA
management for the sepcial-multicast group.

Hence the initial focus in SMuG on group-key and group-SA management,
which happens to be the first piece work to be formally
passed-on from SMuG RG to MSEC WG.

I don't expect the Security-ADs to be aware of this history,
as SMuG was run under the IRTF.  I think the Security-ADs are only aware
of the pieces of SMuG that has been passed-on to MSEC WG.

I copy the following three items below from a piece of text
written in SMuG about 3 years ago regarding the roadmap ahead for SMuG.
(Note that 3 years ago MSEC did not exist).  Item (2) refers to
multicast routing security.

SMuG General Roadmap:
--------------------
1. End-to-End data protection:
    Data protection consists of the application of cryptographic means
    end-to-end to ensure that data delivered through the multicast group
    is protection against illegal modifications (data integrity),
    that the data is verifiable as coming from its original sender (source
    authentication) and that the data is only readable by valid members
    of the group (data confidentiality).  The use of cryptography entails
    the delivery and management of keying material to valid members of
    the group.

2. Multicast distribution tree protection:
    The multicast distribution tree protection typically consists of security
    mechanisms to ensure that tree behavior follows the specified
    protocol.  In practice, this entails the protection of the control
    messages exchanged amongst tree-entities, resulting in the correct
    operation of the tree.  Examples of this includes authentication of
    control messages in M-OSPF and in PIMv2.  Although the aim is
    uniform across all routing protocols, the methods used to achieved
    tree protection is specific to each multicast routing protocol.

3. Membership access control at the subnet level:
    Membership access control at the subnet level consists of
    membership authentication/verification of the Querier (host) in a
    subnet in the context of a specific multicast group.  In general this
    consists of the host proving its membership eligibility to a trusted
    authority in the subnet (eg. an authentication server, the subnet
    router, or others).

thomas
------

At 4/12/2002||08:22 AM, Russ White wrote:
>Y'all:
>
>Due tosome questions which came up elsewhere, I had a brief
>conversation with the ADs about multicast routing security. The
>impression I have from everyone thus far is that the msec group
>is mostly concerned with securing multicast streams, and not the
>multicast routing system. As such, I think it's appropriate to
>assume this group is going to dwal with the same areas of concern
>for multicast routing system security as unicast--defining
>requirements and such, and letting the actual working groups work
>on the protocol specific mechanisms, with this group as a meeting
>ground between the security and multicast routing folks as
>needed/etc.
>
>Just putting this out for comments....
>
>:-)
>
>Russ
>
>__________________________________
>[email-masked] CCIE <>< Grace Alone
>
>
>
>_______________________________________________
>RPSEC mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/rpsec

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 12 Apr 2002 18:17:44 -0400 (EDT)

On Fri, 12 Apr 2002, Thomas Hardjono wrote:

Thomas:

-> Also, if you can solve needs related to unicast routing security, it
-> will also help with some multicast routing protocols For example, a
-> group-authentication or source-authentication method for broadcast of a
-> message in a unicast flood/prune protocol may be useful for a multicast
-> routing protocol that uses a special-multicast-routers group.
->
-> W.R.T. multicast routing and MSEC.  Multicast routing security was part
-> of the SMuG end-goal.  The folks at SMuG quickly realized thatin a
-> multicast routing protocol (e.g. PIM-SM) that employed IP multicast
-> itself to disseminate routing-related messages, some form of
-> cryptographic MAC or signing would be needed.  This, in turn, would
-> need functions for key management, namely group-key management and
-> group-SA management for the sepcial-multicast group.
->
-> Hence the initial focus in SMuG on group-key and group-SA management,
-> which happens to be the first piece work to be formally passed-on from
-> SMuG RG to MSEC WG.

That's exactly it! :-)

Note that the distinction between unicast and multicast RPs is not
necessarily the method used to propagate the information, but the
information that they propagate. 8-)

My point is that unicast RPs (OSPF, for example) *also* use IP multicast
to propagate routing information (the hello protocol and the route
propagation to DRs on a LAN are two examples).  In other words, the work
in MSEC realted to group key management, etc. is definetly of interest to
the unicast RPs...and is part of the "routing system".

Bringing us back to the overlap...or the need to clearly define where the
boundaries are.  If both WGs are going to work on different parts of the
'routing system'...clear limits and collaboration must exist.

My 2c.

Alvaro.

-> 2. Multicast distribution tree protection:
->     The multicast distribution tree protection typically consists of security
->     mechanisms to ensure that tree behavior follows the specified
->     protocol.  In practice, this entails the protection of the control
->     messages exchanged amongst tree-entities, resulting in the correct
->     operation of the tree.  Examples of this includes authentication of
->     control messages in M-OSPF and in PIMv2.  Although the aim is
->     uniform across all routing protocols, the methods used to achieved
->     tree protection is specific to each multicast routing protocol.

---

From: Russ White <[email-masked]>
Date: Sun, 14 Apr 2002 08:38:00 -0400 (EDT)

> Bringing us back to the overlap...or the need to clearly
> define where the boundaries are.  If both WGs are going to
> work on different parts of the 'routing system'...clear
> limits and collaboration must exist.

Agreed.... I think we should address the same stuff in multicast
that we are in unicast--requirements, etc.--and let other groups
do the actual mechanisms. I'm surprised the actual mechanisms
aren't in the pim and other multicast-rp groups, though, rather
than in a security group.

:-)

Russ