> [...]
> > We've based our protocol on both UDP and TCP and have significant
> > reasons for wanting to use UDP. I've seen some reluctance from
> > folks here to pass anything that smells of UDP.
I would like to take a few lines to put my spin on this.
Protocols "work" when they can implement the policy to the letter.
If the policy is based on who has initiated the connection, that
sort of policy sticks well to TCP but slides right off of UDP.
Let's move into the physical world for a bit here...
You had two rooms and between them was a door.
You had a policy that stated that people from room A
could just walk up the the door and enter room B, but
people from room B could not open the door to enter room A, they would
have to get the door opened by someone in room A.
Well, now, that is a clear policy and you could walk down and
get a door knob and lock that would implement that policy.
If the store only sold door knob that from any side of the door,
you could open the door, then you would be stuck trying to implement
policy on a device that could not implement it.
Things start to get real interesting when you have a policy like
"anyone with a blue hat can enter" and all you have is a doorknob
to work with. Time to call MacGyver.
The state based packet filters help you "manage the risk" of
not knowing who really set up the connection of UDP but that
is something that is all that we can do.
If we are doing anything right, our job is to manage risk.
Thanks for listening and there will be a quiz on how many times
I used the word 'policy'. :-)
--blast
References:
|
|
