I guess technically, it doesn't need to be encrypted, as security was not
the goal, it was interoperabilty and management of traffic.
But why not add the benefit of security/encryptions? GRE is one way to do it
(without encryption), but we chose against doing it that way, but I forget
why.
It may be possible to do it with EoIP (IP-IP?), but the problem with these
other methods or similar methods is that they all have greater/significant
negative performance impacts or overhead.
The idea is reduce header overhead and increase data packet size. The reason
we liked CIPE, is that we could not identify any trade off in using it. So
why not use it, if it was the best choice? I've yet to be given a reason why
CIPE is not the best choice.
I will add that we had difficulty/reliability issues with the
authentication components of CIPE, where it would not re-connect properly,
so we disable that step of the protocol most of the time. But why do we
need authentication? Once the tunnel gets established it generally stays
that way for a really long time (until a link failure or reboot). And once
established the data is encrypted.
Tom DeReggi
RapidDSL & Wireless, Inc
IntAirNet- Fixed Wireless Broadband
----- Original Message -----
From: "Jeff Broadwick" <[EMAIL PROTECTED]>
To: "'WISPA General List'" <wireless@wispa.org>
Sent: Thursday, August 03, 2006 1:24 PM
Subject: RE: [WISPA] frame size and fps - Mikrotik large packets
I guess the first question is--does it need to be encrypted? If not, GRE
would
be a better choice (or IP-IP, if interoperability isn't as important). If
it
does need to be encrypted, what are the encryption requirements?
Jeff Broadwick
ImageStream
800-813-5123 x106
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
Of Tom DeReggi
Sent: Wednesday, August 02, 2006 12:17 PM
To: WISPA General List
Subject: Re: [WISPA] frame size and fps - Mikrotik large packets
Jeff,
know that, under Linux, they do that, but it doesn't make it correct.
:-) It just makes it confusing. It's one of the reasons that I think
so many people confuse MTU and MSS.
I agree.
Just for the record, ImageStream supports but does not recommend using
CIPE as our first choice. We highly encourage customers to use
OpenVPN. It is more secure, far more extensible and feature-rich and
has considerable market force behind it (unlike CIPE).
That statement definately needs further clarification, as we need to
define
which applications you are referring to in that comment.
We use and support OPEN VPN on our routers as well. We use it frequently
from
customer's central office to customer's remote offices. We also were
considering
on using it as the VPN method between our Central Management / Monitoring
PCs
and our remote distributed Routers in our network redesign.
For any of those Purposes, specific to a customer or our own use, CIPE
would
not have been our choice. I look at CIPE as a good alternative to IPSEC.
I do
not see how Open VPN could be a replacement for CIPE in the applications
where
we feel CIPE is required.
We use CIPE in one broad application. We need to make a connection
between Cell
Site A and Cell Site B. And between those two cell sites, the
interconnecting
backhaul (usually third party ethernet fiber provider ) does not support
passing
packets with an MTU higher than 1500 bytes. In most cases, the Fiber
provider
uses layer3 private IP addresses to route our data
across their network. To maintain and property distribute our IP space,
we
need to cross these connections in some method of tunneling. We can NOT
chose a
method of tunneling that increases the MTU or the Fiber carrier will not
pass
our data across the circuit without forcing packets to be permanently
fragmented. (some ISPs will drop fragmented packets as well as not
Customer VPN
friendly). We can not chose a tunneling method that shrinks the MTU, as
then
customer's data would not pass our network. The reason for us to tunnel
is to
maintain IP, not to provide optimal security. We need to select a VPN
method
that will work with any other VPN that the customer might use for their
own need
for their corporate network. We need to support "Any/All VPN within our
VPN"
compatibility. To the best of my knowledge, the only tunneling protocol
to be
able to handle this in an amicable way is CIPE. Because CIPE takes care of
spliting the packet to fit into 1500 MTU, and reassemble packet on other
end,
only when needed for optimal performance.
To the best of my knowledge, OPEN VPN does not support this application as
listed above. If you feel Open VPN can accomplish this, please clarify
how.
(On a side note, OPEN VPN is also a technology that supports unique
reasons to
choose Linux routers over name brand applications like Cisco.)
Actually I'm interested in learning/comparing ANY tunneling protocol that
can
accomplsih the above requirements. But performance and compatibilty is a
key
factor. When we selected CIPE, we did it because it was able to solve the
problem in the most efficient manner with the least amount of overhead to
maintain performance.
Tom DeReggi
RapidDSL & Wireless, Inc
IntAirNet- Fixed Wireless Broadband
--
WISPA Wireless List: wireless@wispa.org
Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless
Archives: http://lists.wispa.org/pipermail/wireless/
--
WISPA Wireless List: wireless@wispa.org
Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless
Archives: http://lists.wispa.org/pipermail/wireless/
--
WISPA Wireless List: wireless@wispa.org
Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless
Archives: http://lists.wispa.org/pipermail/wireless/
