Subject: RE: Question for the RFC2961--Refresh reduction--trigger msg

From: "Ferrell, William" <[email-masked]>
Date: Tue, 11 Mar 2003 10:34:06 -0500

Ping  

Hello , I am Will Ferrell of Titan working at DISA on an MPLS security 
project. I have worked with Barry Green (Cisco) on a major DISA ACL project
of which he provided invaluable guidance/support/ tech reference that led to
the projects success.

Ive checked RFC's 2547,3036,2702 et. al.  It appears that there isnt a lot
of interest in securing MPLS. Can you refer me to other work for MPLS
security requirements and all phases of MPLS security to include secure
implementation. 

> > >William Ferrell 
> > >Information Assurance Eng. CCNP 
> > >Titan Corp. 
> > >703-882-2474 

-----Original Message-----
From: Ping Pan
To: Hong Liao
Cc: [email-masked]
Sent: 3/10/03 4:13 PM
Subject: Re: Question for the RFC2961--Refresh reduction--trigger msg

Hong Liao wrote:
> Hi,
> 
> I have question for the trigger message.
> 
> In the RFC2961,section 4.5,
> 
> 
>>>When a node is sending a trigger message, the Message_Identifier
value
>>
> MUST have a value that is greater than any other value previously used
with
> the same Epoch field value.
> 
> so basically if it is a trigger message then message id should be
greater
> than previous one with the same epoch value;but does this mean that if
the
> message id is greater than previous one for the same epoch value, and
the
> rest of the contents are the same as the previous message, then should
the
> message be considered as trigger message ?  Can someone confirm this
for
> me?

Hi,

A couple of points:

1. What qualify as a trigger message on a receiving node?

The idea of refresh reduction is to avoid looking at the content of the 
message. Thus by looking at the message-id, the epoch value, and 
RSVP-hop (that is, incoming interface, RSVP phop address), if there is 
no match to your local table, this is a trigger message. Process the 
message in detail.

2. Why incremental message-id's?

For mis-ordering. When processing a message that carries a message-id, 
from SESSION and SENDER_TEMPLATE, find the flow entry first. If the flow

entry records a message-id greater than what you have received, don't 
process the message - because this is an old junk. (Actually, I didn't 
see this condition in a customer's test net.)

To make sure you are OK with the msg-id roll-over, the routers always 
change to a new epoch number and start to assign messag-id from a small 
value again.

Hope this will help.

- Ping

---

From: Ping Pan <[email-masked]>
Date: Tue, 11 Mar 2003 08:44:25 -0800

Hi,

As for MPLS security, a customer had told me one incident on their 
network: they had received a storm of new RSVP Path messages from 
nowhere, and caused a lot of LSP's to be established. Based on that 
information, I would think you need to get that RFC on RSVP-MD5 working. 
IMHO, you need to take care of spoofing and DOS.

Hope this will help.

- Ping