In-Band Authentication Extension for Protocol Independent Multicast (PIM) draft-bhatia-zhang-pim-auth-extension-00 Manav Bhatia manav.bhatia@alcatel-lucent.com Dacheng Zhang zhangdacheng@huawei.com Hello everybody. I am dacheng, from huawei technologies. Today, I would like to introduce you the work that we have done on an in-band authentication exension for pim.

Problem Statement Existing PIM security mechanisms mandate to use IPsec to provide message authenticity and integrity. No suitable key management mechanism is provided to support multicast. Extremely difficult to use and configure - as a result nobody uses it today. When manual keying is used, the replay protection of IPsec does not work. Replay attacks can seriously disturb the normal operations of PIM For instance, when a PIM router received a hello message with a changed GenID and an re-initialized sequence number, it is difficult for the receiver to distinguish this message from a replay attack. Before introducing our solution, I intend to clarify the problem that we intend to address first. PIM request to use ipsec to provide message original authentication and message integrity protection for pim packets. However, this solution may cause several security issues with replay attacks. PIM may send signal packets using multicast. However, currently there is no suitable key management mechanism provided for supporting multicast. For instance, IKEv2 only supports unicast. GDOI is over complex. According to rfc 4601, when using manual keyed Sas, Ipsec must switch off its anti-replay detection mechanism. Therefore, there is no solution actually help pim to resist replay attacks. Therefore, it is possible for an attacker to impact the state of a pim router by resending a elaborately selected antique message and achieve a successful Dos attack.

Related Work The issues raised by using IPsec to protect OSPFv3 have been discussed in both the KARP and OSPF WGs. The analysis is proposed in draft-ietf-karp-ospf-analysis An in-band security approach is proposed in draft-ietf-ospf-auth-trailer-ospfv3 Applying similar principles in PIM The analysis is done in draft-bhatia-karp-pim-gap-analysis Similar with PIM, OSPFv3 use ipsec to protect its signaling packets and also sends our packet by multicast. The related issues caused by using Ipsec have been discussed and the associated solution has been proposed. We try to take advantage of such experience in ospf to improve the security of PIM.

Solution Define an in-band security solution to replaces IPsec to provide message authenticity, integrity, and freshness. A new type of PIM message is defined that encapsulates and secures other types of PIM messages. Manual keying is assumed The solution does not preclude the possibility of supporting automated keys in future. Our solution is to define an in band in-band security solution to replaces Ipsec. This solution should be provide checking on the authenticity, integrity and freshness on pim packet even there is no automatic key management mechanism provided. We propose a new type of PIM message. This type of message is able to encapsulate and secure another type of PIM packet which we expect to protect.

Packet Format So, this is our solution. This part is the pim packet that we expect to protect。 The type an the reserved field in the original packet header is kept but the pim version and checksum are removed since they are redundant. The packet header of the new type of the packet include key ID to support key update. Sequence number is provide to provide anti-replay services. You may have noted that the length of the sequence number is 64 bits. I will explain why we design in this way in the next slides. The method of generating authentication data has been defined in the document but we won’t go into the detail in this presentation.

Resistance on Replay Attacks: Protection against intra-connection replay attacks: A monotonically increased sequence number is provided The space of the sequence number should be big enough Protection against inter-connection replay attacks: The base solution is subject to inter-connection replay attacks. By using the approach proposed in draft-ietf-ospf-security-extension-manual-keying, this problem can be addressed The first 32 bits of the sequence number is used to count the reboot times which is maintained in non-violated memory Intra-connection replay attack: in which attackers replay the antique messages within the same connection. The inter-connection replay attacks. Which an attacker try to achieve by replaying messages from different connections. The count is stored in a non-violated memory and will be increased by one on every cold reboot. Actually, we copy the idea from the analogous solution in ospf. If you have any comments, you are more than welcome to let us know.

Question? At this stage, it is more important to clarify whether replay attacks should be considered in pim. So, I want to know whether you think the problems I introduced here are important and worthwhile for us to spend more time on.