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

From: [email-masked]
Date: Sat, 13 Mar 2004 23:55:17 EST

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!!!

Putting these messages on two different channels is not the same as assigning 
different priorities with both messages going on the same pipe.  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.

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
it. The only way to ensure this is to mandate it. 

Regards,
Alex.

In a message dated 3/13/2004 4:50:35 PM Central Standard Time, [email-masked] 
writes:
Alex,

On Sat, 2004-03-13 at 14:52, [email-masked] wrote:
> Jamal,
>  
> It is true that the recommendation to use D/C channels can't be
> reflected on the protocol specification. It has more to do with the
> framework than the protocol itself.

Agreed. BTW, didnt mean to repeat some sentences several times on that
last email. I must have hit a cut and paste by mistake

> But it has to be mandated somehow to allow for interoperability. I
> don't see any other way to do this. 

Interoperability is a MUST. Where we disagree is the mandating piece,
and in particular the magic number 2.

> Do you?

I think it is an issue of config to be honest or even implementation.
Solving the problem of how to intermix multicast and unicast connections
also solves this problem. 

> It is just common sense! Carry C/D on separate channels and you 
> decouple the events happening on any one of the channels from 
> impacting on the other. 

Sure. And the difference between the two links is priority. 
And if you had 4 links you could have more granularity and less
impacting of 4 priority levels.
Why 2 only? I dont care what you call them D, C, E, Z;->

> With the increasing threats hackers pose to our networks today, and 
> the increasing important role that the 
> internet plays in our lives (especially commercially), we owe it to
> society to build as 
> secure a network/network element as we can.  

Ah, sure. Traffic going outside the box with no mechanism for being
secured would be a really BAD idea. 
Are you going to lock this second link in a closet so noone has access
to it? Why not make 4 such links for redundancy.

Guys i am trying to work with you so we can can move on. I need to at
least convince myself.

So far i have have heard the following reasoning:
1) separation allows security. Seems to be making some assumptions for
this to be true - as example: theres no way to access the C link from
anywhere and brute force DOS it (fill the pipe with meaningles data).
Otherwise this link is not secure.
If you can guarantee noone access it, isnt that just simply good
engineering and nothing else? Maybe in the appendix soemwhere we can
list Good Practice and make recommendations on configuration.
But why only two channels?
Why the hard coding?

2) separation allows prioritization (at least when links are the
separation point). 
No doubt. Infact the security issue being mentioned is also related to
this issue.
But what has this got to do with having two channels??
Why not 5?

Help me out by responding to those questions. We are beating on this
problem too long.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 14 Mar 2004 07:40:47 -0500

> 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

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