|
At 12:55 PM 8/7/00 -0400, Kyle Sparger wrote:
>> Would this cause any security concerns? Any critical
>> data cross the network should be encrypted to protect
>> the integrity, but that will be a lot of overhead.
>
>What exactly can you do with the information? I can't think of anything
>-- okay, so you know which real server the data is getting sent to. What
>are you gonna do about it?
>
>Is this data so sensitive that we need to worry about the data itself
>being sniffed? Definately we need some kind of authentication method to
>make sure that your random trouble maker can't inject associativity at
>will (possibly creating a denial of service, or worse), but this
>application probably doesn't call for encrypting the _entire_ message.
>(imho)
>
>Mind you, doing the authentication right might _require_ encryption, but
>it might not; I'm just saying that I think that encryption of the data
>for the sake of maintaining the secrecy of the data probably isn't a
>concern.
For those of us have dedicate Internet connection, that might not
be a big deal of security issue. However, for those use LVS in
the hosting services, that could be a problem. Being able to see
the data passing over the wire will allow others to fake data packet
send over from other system. I think that is a security hole.
>> Why don't use serial port? It seems easier than
>> parallel port.
>
>Serial port seems way, way slow to me, and is point-to-point only.
You are right, that is point to point. If you have more than 2
LVS boxes, that will not fit. But the data going back and forth
over the communication port should not be that much. Are
we sure how much data we need to send back and forth?
Slow is a relative term, it depends on how much data going
through it.
>Thanks,
>
>Kyle Sparger - Senior System Administrator
>Dialtone Internet - Extremely Fast Web Systems
>(954) 581-0097 - Voice (954) 581-7629 - Fax
>ksparger@xxxxxxxxxxxxxxxxxxxx
>http://www.dialtoneinternet.net
>
>On Mon, 7 Aug 2000, Wayne wrote:
>
>> At 08:22 PM 8/6/00 +0200, Ratz wrote:
>> >Hi Wensong,
>> >
>> >I've been thinking about our talk at OLS on a possible
>> >kernel-2-kernel masq table syncing (kmasqsd) design.
>> >
>> >To recall:
>> >We decided to implement a kernel daemon like
>> >kflushd that would periodically send new connection
>> >template entries from the master director to the
>> >backup (blaster) over a dedicated heartbeat based
>> >on UDP packets. This is a good basic concept, however,
>>
>> Would this cause any security concerns? Any critical
>> data cross the network should be encrypted to protect
>> the integrity, but that will be a lot of overhead.
>>
>> >I'suggest not to send the updates via UDP but rather
>> >define a own easy protocoll and run it over the
>> >parallel port, since this needs no IP-stack
>>
>> Why don't use serial port? It seems easier than
>> parallel port.
>>
>> >processing and will also work if there is a stack
>> >problem. And in case of a failover and a shutdown
>> >of the interfaces, the daemon could still sync
>> >without being interupted and so providing to
>> >best syncing state. The amount of lost connections
>> >would definitely very small, if not even zero.
>> >
>> >Just a thought ...
>> >Suggestions, flames :) ?
>> >
>> >best regards,
>> >Roberto Nibali, ratz
>> >
>> >
>> >--
>> >mailto: `echo NrOatSz@xxxxxxxxx | sed 's/[NOSPAM]//g'`
>> >
>>
>>
>>
>>
|
