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

From: [email-masked]
Date: Sat, 13 Mar 2004 14:52:08 EST

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.
But it has to be mandated somehow to allow for interoperability. I don't see 
any other
way to do this. Do you?

Cheers,
Alex.

In a message dated 3/13/2004 10:10:28 AM Central Standard Time, [email-masked] 
writes:

David Putzolu wrote:

> My goal with this part of the conversation is merely to show
> that putting everything over a single logical connection (socket)
> severely impinges on the ability to (cleanly) implement 
> any sort of prioritization system on the wire.  This was in 
> response to the assertion made that separate channels don't 
> give us anything.  This part of the discussion is more of a
> theoretical discussion - I am trying to show what I
> believe to be an objective point which is actually independent
> of ForCES itself.
>
> Once that point is cleared up I'll be happy to go into discussing
> the (subjective) point of whether ForCES in particular needs the 
> ability to treat packets differently, and what kind of packets 
> deserve differential treatment.  :)

Ok, agreed. I do think that if you have x physical links
each with different priority that infact you have a good solid
(although more expensive) setup. 
What bothers me is any mandating of one, two, three, .. eight
such channels.
So far i have NOT heard a good reason.
Again, I dont disagree that 2 links is better than one.
or eight for that matter is better than 2. 
My problem is somehow that Forces needs to know this. 
What bothers me is any mandating of one, two, three, .. eight
such channels.
So far i have NOT heard a good reason why. I claim its an 
implementation/config issue (which is orthogonal to Forces).

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 13 Mar 2004 17:48:13 -0500

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

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

---

From: [email-masked]
Date: Sun, 14 Mar 2004 14:04:38 +0900

Hi,

I see several different issues here:

1. when we speak of multiple channels/connections I think we are 
speaking of several different things
  - differential packet marking - e.g. priority
  - different queues for differently marked packets
  - different logical channels
  - different transport layer connections.

I think that the first of these is a protocol issue and  am in complete 
agreement that this must be done.

I think the others are either implementation issues or transport 
encapsulation issues and not specifically protocol issues.

2. Is forcing an ACK for every data packet a sufficient for determining 
the health of a separate data channel.  I suspect it isn't and 
'LMP-like' mechanisms such as heartbeat may also be necessary.  If this 
is what we decide we must be aware that we are adding a control 
mechanism to the data channel. also given that there is a bandwidth 
expense to ACKing every packet and thus a worsening of any DOS threat, 
I assume that a mechanism will be necessary for suppressing the sending 
of every ACK. This makes the necessity of a separate link management 
mechanism necessary for anyone who chooses to use separate connections 
for data more apparent.

3. I think that in case we make the use of a separate transport 
connection optional, it is reasonable to make this a configuration 
parameter, either in the pre-association phase or during the process of 
creating the association.

4. While from an intuitive point of view, separate data channels appear 
to provide security, I have found that such intuitive security 
mechanisms often give a false sense of security.  And given the extra 
risk of attack that separating control and data sometimes causes I 
believe we cannot rely on this as a security solution.  But I am not a 
security expert and think that before we declare this necessary from a 
security pov, we should consult a security expert.

If we are willing to settle on the MUST for differential marking and 
leave the rest for future discussion, we may be able to move on.  If we 
can't I suggest we put this on a second list of issues that require 
further discussion, and we can look at that list at the end and decide 
whether we believe these are show stoppers or just hurdles we have yet 
to overcome.

This points out my belief that we need to determine whether we have 
show-stopper issues to make the required determination regarding a 
merged protocol, we do not need to have solved every issue, not even 
every hard still open issue.

a.

---

From: Jamal Hadi Salim <[email-masked]>
Date: 14 Mar 2004 08:20:35 -0500

Hi Avri,

> agreement that this must be done.

Agreed.

> encapsulation issues and not specifically protocol issues.

Agreed.

> 'LMP-like' mechanisms such as heartbeat may also be necessary.  

BTW, this topic probably should fall under the issue of Availability
(issue #7). 
Havent looked at LMP; I may be going off (#2) topic, but here goes:
I am familiar with other health check/availability schemes like VRRP
which are purely dependent on hearbeats.
The problem with VRRP is it is unidirectional. In this case i would
think from CE to FEs; This provides knowledge to the FEs when CEs go
down but not the other way around. 
In our case, a single message from the CE is sent on the multicast
channel every heartbeat period. Netlink2 has ability to selectively
request for ACKs. So on every third heartbeat message to the FEs, a
request for an ACK is made. We arbitrarly selected number 3. However the
request for ACKs may never be triggered if the state of all FEs is known
to be healthy (example because of recent route add response from all the
FEs).
Additionaly (we never implemented this) you could have responses from
the FEs carry health information (such as link states).
A smart ACK implosion scheme also controls how many FEs respond
to reduce traffic to be processed by CE.

> If this 
> mechanism to the data channel. 

Do you mean control is a message that is terminated
by the CE or FE as opposed of going to the LFB? 
I am still struggling to understand the desire for separation
of links.

> also given that there is a bandwidth 

I think if there exists a good link management protocol that is
sanctioned by the IETF it may make sense to reuse it.
Note however the health checks may involve more than links.

> creating the association.

Agreed. Preassociation is the config phase.

> security pov, we should consult a security expert.

I think if the separate channel is NOT accessible it may provide some
sense of security until someone finds a way to access it - in which case
it becomes another channel that can be DOSed.

> leave the rest for future discussion, we may be able to move on.  If we 

Sounds reasonable to me.

> whether we believe these are show stoppers or just hurdles we have yet 

To me it looks like more of a hurdle. To be honest i havent liked any of
the reasoning i have seen so far. I want to jump on the boat but it has
to make some sense we are not going towards a waterfall.

> every hard still open issue.

I agree. We need to move on. 
We should also be able to close issue #3.
Any objections?

cheers,
jamal

---

From: [email-masked]
Date: Sun, 14 Mar 2004 21:37:07 +0800

Hi,

I am not suggesting that we use LMB.  What I am suggesting is that is 
we have a separate connection that does not fate-share with the 
control, then we need to have a monitor it. I..e something that 
monitors that link.

a.

---

From: Jamal Hadi Salim <[email-masked]>
Date: 14 Mar 2004 21:29:58 -0500

Agreed.

cheers,
jamal