One document matched: draft-ietf-pim-sm-linklocal-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc4601 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4601.xml">
<!ENTITY rfc4302 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4302.xml">
<!ENTITY rfc4301 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml">
<!ENTITY rfc3740 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3740.xml">
<!ENTITY rfc2401 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2401.xml">
<!ENTITY rfc4303 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4303.xml">
<!ENTITY rfc4305 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4305.xml">
<!ENTITY rfc4306 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4306.xml">
<!ENTITY rfc4535 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4535.xml">
<!ENTITY rfc3547 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3547.xml">
<!ENTITY rfc4593 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4593.xml">
<!ENTITY I-D.ietf-pim-lasthop-threats SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pim-lasthop-threats.xml">
<!ENTITY rfc4609 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4609.xml">
]>
<?rfc toc="yes"?>
<rfc category="std" updates="4601" docName="draft-ietf-pim-sm-linklocal-02" ipr="full3978">
<front>
<title abbrev="PIM-SM Link-local Security">Authentication and Confidentiality in PIM-SM
Link-local Messages</title>
<author fullname="J. William Atwood" initials="W." surname="Atwood">
<organization>Concordia University/CSE</organization>
<address>
<postal>
<street>1455 de Maisonneuve Blvd, West</street>
<city>Montreal</city>
<region>QC</region>
<code>H3G 1M8</code>
<country>Canada</country>
</postal>
<phone>+1(514)848-2424 ext3046</phone>
<email>bill@cse.concordia.ca</email>
<uri>http://users.encs.concordia.ca/~bill</uri>
</address>
</author>
<author fullname="Salekul Islam" initials="S." surname="Islam">
<organization>Concordia University/CSE</organization>
<address>
<postal>
<street>1455 de Maisonneuve Blvd, West</street>
<city>Montreal</city>
<region>QC</region>
<code>H3G 1M8</code>
<country>Canada</country>
</postal>
</address>
</author>
<date day="18" month="November" year="2007"></date>
<area>Routing</area>
<workgroup>PIM Working Group</workgroup>
<keyword>Security</keyword>
<keyword>PIM-SM</keyword>
<abstract>
<t>RFC 4601 mandates the use of IPsec to ensure authentication of the link-local
messages in the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing
protocol. This document specifies mechanisms to authenticate the PIM-SM link local
messages using the IP security (IPsec) Authentication Header (AH) or Encapsulating Security Payload (ESP). It specifies optional mechanisms to provide confidentiality using the ESP. Manual keying is specified as the mandatory and default group key management solution. To deal with issues of scalability and security that exist with manual keying, an optional automated group key management mechanism is specified.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>All the PIM-SM <xref target="RFC4601"></xref> control
messages have IP protocol number 103. These messages are either unicast,
or multicast with TTL = 1. The source address used for unicast messages
is a domain-wide reachable address. For the multicast messages, a
link-local address of the interface on which the message is being sent
is used as the source address and a special multicast address,
ALL_PIM_ROUTERS (224.0.0.13 in IPv4 and ff02::d in IPv6) is used as the
destination address. These messages are called link-local messages.
Hello, Join/Prune and Assert messages are included in this category. A
forged link-local message may be sent to the ALL_PIM_ROUTERS multicast
address by an attacker. This type of message affects the construction of
the distribution tree <xref target="RFC4601"></xref>. The
effects of these forged messages are outlined in section 6.1 of <xref target="RFC4601"></xref>. Some of the effects are very
severe, whereas some are minor.</t>
<t>PIM-SM version 2 was originally specified in RFC 2117, and revised in
RFC 2362 and RFC 4601. RFC 4601 obsoletes RFC 2362, and
corrects a number of deficiencies. The Security Considerations section of
RFC 4601 is based primarily on the new Authentication
Header (AH) specification described in <xref target="RFC4302">RFC
4302</xref>.</t>
<t>Securing the unicast messages can be achieved by the use of a normal
unicast IPsec Security Association between the two communicants.
Securing the user data exchanges is covered in <xref target="RFC3740">RFC 3740</xref>. This document focuses on the security issues
for link-local messages. It provides some guidelines to take advantage of
the new permitted AH functionality in RFC 4302, and to bring the PIM-SM specification into alignment with the new AH specification. This document
recommends manual key management as mandatory to implement, i.e., that all
implementations MUST support, and begins the discussion of an automated key management protocol that the PIM routers can use.</t>
</section>
<section title="Terminology">
<t>In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref> and indicate
requirement levels for compliant PIM-SM implementations.</t>
</section>
<section title="Transport Mode vs. Tunnel Mode">
<t>The transport mode Security Association (SA) is generally used
between two hosts or routers/gateways when they are acting as hosts. The
SA must be a tunnel mode SA if either end of the security association is
a router/gateway. Two hosts MAY establish a tunnel mode SA between
themselves. PIM-SM link-local messages are exchanged between routers.
However, since the packets are locally delivered, the routers assume the
role of hosts in the context of the tunnel mode SA. All implementations
conforming to this specification MUST support transport mode SA to
provide required IPsec security to PIM-SM link-local messages. They MAY
also support tunnel mode SA to provide required IPsec security to PIM-SM
link-local messages.</t>
</section>
<section title="Authentication">
<t>Implementations conforming to this specification MUST support
authentication for PIM-SM link-local messages.</t>
<t>In order to provide
authentication to PIM-SM link-local messages, implementations MUST
support <xref target="RFC4303">ESP</xref> and MAY support <xref target="RFC4302">AH</xref>.</t>
<t>If ESP in transport mode is used, it will only provide authentication to PIM-SM protocol packets excluding the IPv6 header, extension headers, and options. (Note: The IPv4 exclusions need to be listed here as well.)</t>
<t>If AH in transport mode is used, it will provide authentication to PIM-SM protocol packets, selected portions of the IPv6 header, extension headers and options. (Note: the IPv4 coverage needs to be listed here as well.)</t>
<t>When authentication for PIM-SM link-local messages is enabled, <list style="symbols">
<t>PIM-SM link-local packets that are not protected with AH or ESP MUST be
silently discarded.</t>
<t>PIM-SM link-local packets that fail the authentication checks
MUST be silently discarded.</t>
</list>
</t>
</section>
<section title="Confidentiality">
<t>Implementations conforming to this specification SHOULD support confidentiality for PIM-SM.</t>
<t>If confidentiality is provided, ESP MUST be used.</t>
<t>When PIM-SM confidentiality is enabled,<list style="symbols">
<t>PIM-SM packets that are not protected with ESP MUST be silently discarded.</t>
<t>PIM-SM packets that fail the confidentiality checks MUST be silently discarded.</t>
</list>
</t>
</section>
<section title=" IPsec Requirements">
<t>In order to implement this specification, the following IPsec
capabilities are required.</t>
<t>
<list style="hanging">
<t hangText="Transport mode">
<vspace blankLines="0"></vspace>IPsec in
transport mode MUST be supported.</t>
<t hangText="Multiple Security Policy Databases (SPDs)">
<vspace blankLines="0"></vspace>The implementation MUST support multiple SPDs with an SPD selection function that provides an ability to choose a specific SPD based on interface.</t>
<t hangText="Selectors">
<vspace blankLines="0"></vspace>The implementation
MUST be able to use source address, destination address, protocol, and direction as selectors in the
SPD.</t>
<t hangText="Interface ID tagging">
<vspace blankLines="0"></vspace>The implementation MUST be able to tag the inbound packets with the ID of the interface (physical or virtual) via which it arrived.</t>
<t hangText="Manual key support">
<vspace blankLines="0"></vspace>Manually configured keys MUST be able to secure the
specified traffic.</t>
<t hangText="Encryption and authentication algorithms">
<vspace blankLines="0"></vspace>The implementation MUST NOT allow the user to choose stream ciphers as the encryption algorithm for securing PIM-SM packets since the stream ciphers are not suitable for manual keys. Except when in conflict with the above statement, the key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", and "SHOULD NOT" that appear in <xref target="RFC4305">RFC 4305</xref> for algorithms to be supported are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref> for PIM-SM support as well.</t>
<t hangText="Encapsulation of ESP packet">
<vspace blankLines="0"></vspace>IP encapsulation of ESP packets MUST be supported. For simplicity, UDP encapsulation of ESP packets SHOULD NOT be used.</t>
</list>
</t>
</section>
<section title="Key Management">
<t>All the implementations MUST support manual configuration of the SAs
that will be used to authenticate PIM-SM link-local messages. This does not preclude the use of a negotiation protocol such as the
Internet Key Exchange (IKE) <xref target="RFC4306"></xref> or Group
Secure Association Key Management Protocol (GSAKMP) <xref target="RFC4535"></xref> to establish SAs.</t>
<section title="Manual Key Management"></section>
<t>To establish the SAs at PIM-SM routers, manual key configuration will
be feasible when the number of peers (directly connected routers) is
small. The Network Administrator will configure a router manually during
its boot up process. At that time, the authentication method and the choice
of keys SHOULD be configured. The SAD entry will be created. The Network
Administrator will also configure the Security Policy Database of a router to
ensure the use of the associated SA while sending a link-local
message.</t>
<section title="Automated Key Management"></section>
<t>All the link-local messages of the PIM-SM protocol are sent to the
destination address, ALL_PIM_ROUTERS, which is a multicast address. By
using the sender address in conjunction with the destination address for
Security Association lookup, link-local communication turns to an SSM or
"one to many" communication. Since IKE is based on the Diffie-Hellman
key agreement protocol and works only for two communicating parties, it
is not possible to use IKE for providing the required "one to many"
authentication.</t>
<t>One option is to use Group Domain Of Interpretation (GDOI)
<xref target="RFC3547"></xref>, which enables a group of users or
devices to exchange encrypted data using IPsec data encryption. GDOI has
been developed to be used in multicast applications, where the number of
end users or devices may be large and the end users or devices can
dynamically join/leave a multicast group. However, a PIM router is not
expected to join/leave very frequently, and the number of routers is
small when compared to the possible number of users of a multicast application. Moreover,
most of the PIM routers will be located inside the same administrative
domain and are considered as trusted parties. It is possible that a
subset of GDOI functionalities will be sufficient.</t>
<section title="Communications Patterns">
<t>
Before discussing the set of security associations that are required to properly manage a multicast region that is under the control of a single administration, it is necessary to understand the communications patterns that will exist among the routers in this region. From the perspective of a speaking router, the information from that router is sent (multicast) to all of its neighbors. From the perspective of a listening router, the information coming from each of its neighbors is distinct from the information coming from every other router to which it is directly connected. Thus an administrative region contains many (small) distinct groups, all of which happen to be using the same multicast destination address (e.g., ALL_PIM_ROUTERS, see <xref target="SAlookup"></xref>), and each of which is centered on the associated speaking router.</t>
<t>Consider the example configuration as shown in Figure 1.</t>
<t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
R2 R3 R4 R5 R6
| | | | |
| | | | |
--------- ---------------
| |
| |
\ /
R1
/ \
| |
| |
--------- --------------------
| | | | |
| | | | |
R7 R8 R9 R10 R11
| | | | |
|
|
-------------
| | |
| | |
R12 R13 R14
Figure 1: Set of router interconnections]]></artwork>
<postamble></postamble>
</figure>
</t>
<t>In this configuration, router R1 has four interfaces, and is the speaking router for a group whose listening routers are routers R2 through R11. Router R9 is the speaking router for a group whose listening routers are routers R1, R8 and R10-R14.</t>
<t>From the perspective of R1 as a speaking router, if a Security Association SA1 is assigned to protect outgoing packets from R1, then it is necessary to distribute the key for this association to each of the routers R2 through R11. Similarly, from the perspective of R9 as a speaking router, if a Security Association is assigned to protect the outgoing packets from R9, then it is necessary to distribute the key for this association to each of the routers R1, R8, and R10 through R14.</t>
<t>From the perspective of R1 as a listening router, all packets arriving from R2 through R11 need to be distinguished from each other, to permit selecting the correct Security Association in the SAD. (Packets from each of the peer routers (R2 through R11) represent communication from a different speaker, even though they are sent using the same destination address.) For a multicast Security Association, RFC 4301 permits using the Source Address in the selection function. If the source addresses used by routers R2 through R11 are globally unique, then the source addresses of the peer routers are sufficient to achieve the differentiation. If the sending routers use link-local addresses, then these addresses are unique only on a per-interface basis, and it is necessary to use the Interface ID tag as an additional selector, i.e., either the selection function has to have the Interface ID tag as one of its inputs, or separate SADs have to be maintained for each interface.</t>
<t>If the assumption of connectivity to the key server can be made (which is true in the PIM-SM case), then the GC/KS can be centrally located (and duplicated for reliability). If this assumption cannot be made (i.e., in the case of adjacencies for a unicast router), then some form of "local" key server must be available for each group. Given that the listening routers are never more than one hop away from the speaking router, the speaking router is the obvious place to locate the "local" key server. This has the additional advantage that there is no need to duplicate the local key server for reliability, since if the key server is down, it is very likely that the speaking router is also down.</t>
</section>
<section title="Neighbor Relationships">
<t>Each distinct group consists of one speaker, and the set of directly connected listeners. If the decision is made to maintain one Security Association per speaker (see <xref target="numberSA"></xref>), then the key server will need to be aware of the adjacencies of each speaker. Procedures for doing this are under study.</t>
</section>
</section>
<section title="Number of Security Associations" anchor="numberSA">
<t>The number of Security Associations to be maintained by a PIM router
depends on the required security level and available key management.
This SHOULD be decided by the Network Administrator. Two different ways are
shown in Figure 2 and 3. It is assumed that A, B and C are three PIM
routers, where B and C are directly connected with A, and there is no
direct link between B and C.</t>
<t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
|
B |
SAb ------------>|
SAa <------------|
|
A |
SAb <------------|
SAa ------------>|
SAc <------------|
|
C |
SAc ------------>|
SAa <------------|
|
Directly connected network
Figure 2: Activate unique Security Association for each peer]]></artwork>
<postamble></postamble>
</figure>
</t>
<t>The first method, shown in Figure 2 is OPTIONAL to implement. In this
method, each node will use a unique SA for its outbound traffic. A, B,
and C will use SAa, SAb, and SAc, respectively for sending any traffic.
Each node will look up the SA to be used based on the source address. A
will use SAb and SAc for packets received from B and C, respectively.
The number of SAs to be activated and maintained by a PIM router will be
equal to the number of directly connected routers plus one, for sending
its own traffic. Also, the addition of a PIM router in the network will
require the addition of another SA on every directly connected PIM
router. This solution will be scalable and practically feasible with an
automated key management protocol. However, it MAY be used with manual
key management, if the number of directly connected router(s) is
small.</t>
<t>
<figure>
<preamble></preamble>
<artwork><![CDATA[ B |
SAo ------------>|
SAi <------------|
|
A |
SAo ------------>|
SAi <------------|
|
C |
SAo ------------>|
SAi <------------|
|
Directly connected network
Figure 3: Activate two Security Associations
]]></artwork>
<postamble></postamble>
</figure>
</t>
<t>The second method, shown in Figure 3, MUST be supported by every
implementation. In this simple method, all the nodes will use two SAs,
one for sending (SAo) and the other for receiving (SAi) traffic. Thus, the
number of SAs is always two and will not be affected by addition of a
PIM router. Although two different SAs are used in this method, the encryption key for the two SAs is identical, i.e., it is a single key shared among all the routers in an administrative region. This document RECOMMENDS the above method for manual key
configuration. However, it MAY also be used with automated key configuration.
When manually configured, the method suffers from impersonation
attacks as mentioned in the Security Considerations section.</t>
</section>
<section title="Rekeying">
<t> This section will provide the rekeying rules. It will be written once is is decided whether or not to specify a re-keying protocol as part of this document.</t>
<section title="Rekeying Procedure">
<t>TBD</t>
</section>
<section title="KeyRollover Interval">
<t>TBD</t>
</section>
<section title="Rekeying Interval">
<t>TBD</t>
</section>
</section>
<section title="IPsec Protection Barrier and SPD">
<t>This section will provide the SPD selection function rules. It will be written once it is decided whether to retain both confidentiality and authentication, or to limit the recommendation to authentication.</t>
</section>
<section title="Security Association Lookup" anchor="SAlookup">
<t>For an SA that carries unicast traffic, three parameters (SPI,
destination address and security protocol type (AH or ESP)) are used in
the Security Association lookup process for inbound packets. The SPI is
sufficient to specify an SA. However, an implementation may use the SPI
in conjunction with the IPsec protocol type (AH or ESP) for the SA
lookup process. According to RFC 4301 <xref target="RFC4301"></xref> and
the AH specification <xref target="RFC4302"></xref>, for multicast SAs,
in conjunction with the SPI, the destination address or the destination
address plus the sender address may also be used in the SA lookup. The
security protocol field is not employed for a multicast SA lookup.</t>
<t>The reason for the various prohibitions in the IPsec RFCs concerning
multisender multicast SAs lies in the difficulty of coordinating the
multiple senders. However, if the use of multicast for link-local
messages is examined, it may be seen that in fact the communication need
not be coordinated---from the prospective of a receiving router, each
peer router is an independent sender. In effect, link-local
communication is an SSM communication that happens to use an ASM address
(which is shared among all the routers).</t>
<t>Given that it is always possible to distinguish a connection using IPsec from a connection not using IPsec, it is recommended that the address ALL_PIM_ROUTERS be used, to maintain consistency with present practice.</t>
<t>Given that the sender address of an incoming packet may be only locally unique (because of the use of link-local addresses), it will be
necessary for a receiver to use the interface ID tag to sort out the associated SA for
that sender. Therefore, this document mandates that the interface ID tag,
the SPI and the sender address MUST be used in the SA lookup
process.</t>
</section>
<section title="Activating the Anti-replay Mechanism">
<t>Although link-level messages on a link constitute a multiple-sender,
multiple-receiver group, the use of the interface ID tag and sender address for SA lookup
essentially resolves the communication into a separate SA for each
sender/destination pair, even for the case where only two SAs (and one shared key) are used for the entire administrative region. Therefore, the statement in the AH RFC (section
2.5 of <xref target="RFC4302"></xref>) that "for a multi-sender SA, the
anti-replay features are not available" becomes irrelevant to the PIM-SM
link-local message exchange.</t>
<t>To activate the anti-replay mechanism in a unicast communication, the
receiver uses the sliding window protocol and it maintains a sequence
number for this protocol. This sequence number starts from zero. Each
time the sender sends a new packet, it increments this number by one. In
a multi-sender multicast group communication, a single sequence number
for the entire group would not be enough.</t>
<t>The whole scenario is different for PIM link-local messages. These
messages are sent to local links with TTL = 1. A link-local message
never propagates through one router to another. The use of the sender
address and the interface ID tag for SA lookup converts the relationship from a multiple-sender
group to multiple single-sender associations. This specification
RECOMMENDS activation of the anti-replay mechanism only if the SAs are
assigned using an automated key management. In manual key management,
the anti-replay SHOULD NOT be activated. If the number of router(s) to
be assigned manually is small, the Network Administrator MAY consider to
activate anti-replay. If anti-replay is activated a PIM router MUST
maintain a different sliding window for each directly connected
sender.</t>
<t>If the SAs are activated according to Figure 3, that is all the nodes
use only two SAs, one SA for sending and the other is for receiving
traffic, a PIM router MAY still activate the anti-replay mechanism. Instead
of maintaining only two SAs, the router will maintain the same number of
SAs as explained in the first method (see Figure 2) (because of the differentiation based on sender address). For each active SA
a corresponding sequence number MUST be maintained. Thus, a PIM router
will maintain a number of identical SAs, except that the sender address, interface ID tag and
the sequence number are different for each SA. In this way a PIM router will be at least
free from all the attacks that can be performed by replaying PIM-SM
packets.</t>
<t>Note that when activating anti-replay with manual key configuration, the following actions must be taken by the network administrator:</t>
<t>
<list style="letters">
<t>If a new router is added, the Network Administrator MUST add a new SA entry in each peer router.</t>
<t>If an existing router has to restart, the Network Administrator MUST refresh the counter (ESN, see <xref target="ESN"></xref>) to zero for all the peer routers. This implies deleting all the existing SAs and adding a new SA with the same configuration and a re-initialized counter.</t>
</list>
</t>
</section>
<section title="Implementing a Security Association Database per Interface">
<t>RFC 4601 suggests that it may be desirable to implement a separate Security Association Database (SAD) for each router interface.
The use of link-local addresses in certain circumstances implies that differentiation of ambiguous speaker addresses requires the use of the interface ID tag in the SA lookup. One way to do this is through the use of multiple SADs. Alternatively, the interface ID tag may be a specific component of the selector algorithm. This is in conformance with RFC 4301, which explicitly removes the requirement for separate SADs that was present in RFC 2401 <xref target="RFC2401"></xref>.</t>
</section>
<section title="Extended Sequence Number" anchor="ESN">
<t>In the <xref target="RFC4302"></xref>, there is a provision for a
64-bit Extended Sequence Number (ESN) as the counter of the sliding
window used in the anti-replay protocol. Both the sender and the
receiver maintain a 64-bit counter for the sequence number, although
only the lower order 32 bits is sent in the transmission. In other
words, it will not affect the present header format of AH. If ESN is
used, a sender router can send 2^64 -1 packets without any intervention.
This number is very large, and from a PIM router's point of view, a PIM
router can never exceed this number in its lifetime. This makes it
reasonable to permit manual configuration for a small number of PIM
routers, since the sequence number will never roll over. For this
reason, when manual configuration is used, ESN SHOULD be deployed as the
sequence number for the sliding window protocol.</t>
</section>
<section title="Security Considerations">
<t>The whole document considers the security issues of PIM link-local
messages and proposes a mechanism to protect them.</t>
<t>Limitations of manual keys:</t>
<t>The following are some of the known limitations of the usage of
manual keys.</t>
<t>
<list style="symbols">
<t>If replay protection cannot be provided, the PIM routers will not
be secured against all the attacks that can be performed by
replaying PIM packets.</t>
<t>Manual keys are usually long lived (changing them often is a
tedious task). This gives an attacker enough time to discover the
keys.</t>
<t>As the administrator is manually configuring the keys, there is a
chance that the configured keys are weak (there are known weak keys
for DES/3DES at least).</t>
</list>
</t>
<t>Impersonation attacks:</t>
<t>The usage of the same key on all the PIM routers connected to a link
leaves them all insecure against impersonation attacks if any one of the
PIM routers is compromised, malfunctioning, or misconfigured.</t>
<t>Detailed analysis of various vulnerabilities of routing protocols is
provided in <xref target="RFC4593">RFC 4593</xref>. For
further discussion of PIM-SM and multicast security the reader is
referred to <xref target="I-D.ietf-pim-lasthop-threats"></xref>, <xref target="RFC4609">RFC 4609</xref> and the Security
Considerations section of <xref target="RFC4601">RFC 4601</xref>.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc4601;
&rfc4302;
&rfc2119;
&rfc4301;
&rfc4303;
&rfc3740;
&rfc4305;
</references>
<references title="Informative References">
&rfc2401;
<reference anchor="IslamThesis">
<front>
<title>Security Issues in PIM-SM Link-local Messages, Master's
Thesis, Concordia University</title>
<author fullname="Salekul Islam" initials="S." surname="Islam">
<organization>Master's Thesis, Concordia University, Department of
Computer Science and Software Engineering</organization>
</author>
<date month="December" year="2003"></date>
</front>
</reference>
<reference anchor="IslamLCN2004">
<front>
<title>Security Issues in PIM-SM Link-local Messages, Proceedings of
LCN 2004</title>
<author fullname="Salekul Islam" initials="S." surname="Islam">
<organization>Proceedings of IEEE LCN 2004</organization>
</author>
<date month="November" year="2004"></date>
</front>
</reference>
&rfc4306;
&rfc4535;
&rfc3547;
&rfc4593;
&I-D.ietf-pim-lasthop-threats;
&rfc4609;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 07:16:20 |