Subject: Re: [Forces-protocol] Issue 2: Multiple channels/connections

From: [email-masked]
Date: Sun, 14 Mar 2004 18:37:04 EST

Hi Jamal,

Redirected packets are definitely different in terms of payload from control 
packets.
In FACT, this is indicated by giving them different message classes (and 
types). 

What is the point being put across with the five links/channels issue? I 
really don't
understand that.

It is harder to DOS the C link because it is not exposed to packets from 
outside the
NE. Redirected packets are foreign packets (in origin) and are very 
succeptible to
manipulation by hostile third parties. Hence D link will be more vulnerable 
to attacks.

Regards,
Alex.

In a message dated 3/14/2004 6:41:07 AM Central Standard Time, [email-masked] 
writes:
On Sat, 2004-03-13 at 23:55, [email-masked] wrote:
> OK,..so we give it another try.
>  
> Why two and not five or six?  Because we are dealing with two message
> types: 
> Control messages and Redirected (Data) messages!!!

Are redirected data packets different in from normal control messages
in terms of encapsulation? i.e are they NOT wrapped around using the
ForCES protocol headers? In our implementation they were. Hence probably
my bias.
If they are transported within a ForCES message, what makes them require
to be on a separate link in comparison to more a response to a commit of
a "route add"?
I would think that events are another class, btw. But thats a
digression.

Something else:
If you had 5 links available for management, in your scenario, you cant
use them all, correct? You can only use two?

> Putting these messages on two different channels is not the same as
> assigning different priorities with both messages going on the same
> pipe.  

Depends on the nature of the pipe. If you send on one thats known to be
less congested vs a congested one then you are prioritizing.

> And priorities can't help you in the DOS scenario we are concerned
> about beacuse can't  you first need to pull the packet off the queue
> or channel, check the priority before deciding what to do with it.
>  You can imagine how many CPU cycles it takes to 
> do that.  And if you have to do this for a million D packets before
> you get to a C 
> packet, you may lose a lot of valuable time before you have a chance
> to mitigate 
> the problem.

We did agree that 2 physical links are better than one; and
8 are better than 2.
We also did agree that if all of those Links are being DoSed using
something that just fills the pipe, then it doesnt matter
if you had one or eight.
You seem to say that this C link is somehow never susceptible to such an
attack? Then it would make sense. But what has that got to do with 
the ForCES protocol?

> You say it is an issue of configuration. How can something be
> configured if it does
> not exist? For it to be configured, ForCES protocol on both FE and CE
> must support

Sure; i meant configuration on both sides.
Pick any protocol, and you need parameters; try to set two
OSPF capable devices in different areas and you will quickly
run into issues.

> it. The only way to ensure this is to mandate it. 

Are you mandating that a ForCES FE MUST have two physical links?
i.e the few million devices out there with one physical management link
cannot be used? Iam afraid that I violently disagree with that.

I am gonna add to my list of "why we need two links":
0) We need two links and two links only because we have ONLY two classes
of traffic: Data and control. 
1) separation (using two links)allows security.
2) separation (suing two links) allows prioritization

cheers,
jamal

---

From: [email-masked]
Date: Mon, 15 Mar 2004 09:09:07 +0800

On 15 mar 2004, at 07.37, [email-masked] wrote:

>
> It is harder to DOS the C link because it is not exposed to packets 
> from outside the
> manipulation by hostile third parties. Hence D link will be more 
> vulnerable to attacks.
>  

While the FE don't need to respond to messages from non authroized 
elements, in a configuration that includes an external link between the 
CE and Fe, a malicious system could indeed direct packets at the CE and 
FE across the C channel.

I would assume the risk is the same as with inter-fe traffic when they 
are on a external link.  On an internal link I would not expect that 
either would be more prone then the other.

In fact it is not intuitively obvious to me while the risk on either 
link is greater then on the other.

a.

_______________________________________________
Forces-protocol mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/forces-protocol

---

From: Jamal Hadi Salim <[email-masked]>
Date: 14 Mar 2004 22:14:55 -0500

On Sun, 2004-03-14 at 18:37, [email-masked] wrote:
> Hi Jamal,
>  
> Redirected packets are definitely different in terms of payload from
> control packets.
> In FACT, this is indicated by giving them different message classes
> (and types). 

So no different than GRMP or Netlink2. I.e you take the data packet,
wrap a header around it and ship it to the CE.

> What is the point being put across with the five links/channels issue?
> I really don't understand that.

If you had five separate physical links instead of two, could you use 
all of them? Or would you only use two out of the five?

> from outside the NE. Redirected packets are foreign packets (in
> origin) and are very succeptible to manipulation by hostile third
> parties. Hence D link will be more vulnerable to attacks.

This is a weak but valid point. Assuming of course:
a) Assuming a "foreign" (read: multihop ) CE cant be talking
to an FE.

Or:
b) CE and FE are NOT accessible from the outside world. sounds
very difficult to me since the NE would be accessible.

and/or
c) that the dedicated C link is infact within a chasis only.
That if you go across chasis or a network you also have these
dedicated C channels as in SS7. A very expensive proposition.
You realize that people are moving towards unified IP based networks to
avoid all these costs, dont you? Infact if memory serves me right SCTP
was created so it could carry SS7 traffic initially.

cheers,
jamal