Subject: [pim] PIM Todo List (resent w/corrected address)

From: Beau Williamson <[email-masked]>
Date: Wed, 12 Dec 2001 15:01:49 -0600

Mark et al, 

I think we should add PIM message security (i.e. authentication) to the PIM Spec todo list.  There are numerous DoS attacks that can be mounted against PIM if we don't address this.

Beau Williamson

P.S. Sorry I couldn't be at the IETF meeting this time but I'm watching from home.

---

From: Mark Handley <[email-masked]>
Date: Wed, 12 Dec 2001 12:54:37 -0800

>I think we should add PIM message security (i.e. authentication) to the PIM Sp
>ec todo list.  There are numerous DoS attacks that can be mounted against PIM 
>if we don't address this.

I think the security section includes message authentication.  In
general, this section needs review, but is there anything specific you
think is wrong or missing?

Cheers,
	Mark

---

From: "Prashant Jhingran" <[email-masked]>
Date: Thu, 13 Dec 2001 16:15:24 +0530

hi ,
    Well the authors have done a great work by pointing out the possible
security loopholes.
I think that "Register Nonce" if implemented can provide a good
authentication mechanism for register and register stop packets between the
RP and SDR.
Unfortunately the writers have not suggested where the "nonce" have to be
placed in the register /register-stop packets.
The field have to properly chosen so that there shouldn't be any interop
problem....and it can be made as a "MUST" for implementation.

regards,
Prashant

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Mark
Handley
Sent: Thursday, 13 December 2001 2:25 AM
To: Beau Williamson
Cc: [email-masked]
Subject: [pim] Re: PIM Todo List (resent w/corrected address)

Cheers,
	Mark

---

From: Beau Williamson <[email-masked]>
Date: Thu, 13 Dec 2001 10:08:12 -0600

>think is wrong or missing?

Sorry, I was looking at the wrong version.  However, while I've got your attention, why didn't we use something a little lighter weight?  I thought Liming had proposed a message authentication that also had some sort of MD5, light weight authentication.

I'm sure this was discussed but I'm interested why you went the way you did. 

Beau

---

From: Hugh Holbrook <[email-masked]>
Date: Thu, 13 Dec 2001 10:31:49 -0800 (PST)

Prashant,

We actually removed the Register Nonce mechanism from the latest
version of the spec, despite the fact that we (the authors) sort of
liked it.  We did this because the Security ADs told us that it was
not acceptable to standardize anything less than cryptographic
security.

Beau, the current spec doesn't prevent one from using HMAC MD5 as an
authentication mechanism (at least, I don't think so) -- it merely
says that you should use the IPSec AH framework to do it.

-Hugh

> From: "Prashant Jhingran" <[email-masked]>
> Cc: <[email-masked]>
> Date: Thu, 13 Dec 2001 16:15:24 +0530
> 
> hi ,

---

From: Liming Wei <[email-masked]>
Date: Thu, 13 Dec 2001 10:51:14 -0800 (PST)

> Date: Thu, 13 Dec 2001 10:08:12 -0600
> From: Beau Williamson <[email-masked]>
> 
> Sorry, I was looking at the wrong version. However, while I've got
> your attention, why didn't we use something a little lighter weight?
> I thought Liming had proposed a message authentication that also had
> some sort of MD5, light weight authentication.

The reason I did it that way was because I wanted the spec to be
self-contained and easily understood by the implementors and network
designers, who may not (want to) understand the whole deal with IPSEC,
or know which version of the IPSEC specification to follow.

I included the packet format, and *specific* information about the
digest algorithms, and key distribution methods to use, even though it
might look redundant, to make sure the details are clearly
specified, and would not move as the IPSEC work moves (though unlikely
but it did happen before I published my draft initially). That way the
implementors can have all information from the PIM draft(s). It also
helps folks who need to deploy this stuff.

I sure hope the new spec would maintain such usability to the
implementation and deployment efforts.

> I'm sure this was discussed but I'm interested why you went the way you did. 

-Liming