Pawel Foremski writes:
> For example because MPPE is optional and some sessions may be encrypted and
> some not. As I mentioned, we cannot influence the ISP in topic.
>
> More generally, I wanted to present an example of a layer-2 encapsulation
> that Linux does not know or (as in this case)
Stephen Hemminger wrote:
> Ethernet encrypted bridging is old stuff:
> http://kerneltrap.org/node/167
> http://www.arnor.net/encryptingbridge/
>
> It never got accepted, mostly for the same reasons this proposal
> is a dead end.
>From what I can see in the brief description is that ccrypt is mor
Stephen J. Bevan wrote:
> However, in the above you note that MPPE is being used. I take this
> to mean that all the PPP traffic between the PPPoE client and PPPoE
> server is encrypted. However, if that's the case then I don't
> understand why there is a need to use ccrypt for the wireless link
Ethernet encrypted bridging is old stuff:
http://kerneltrap.org/node/167
http://www.arnor.net/encryptingbridge/
It never got accepted, mostly for the same reasons this proposal
is a dead end.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PRO
From: [EMAIL PROTECTED] (Stephen J. Bevan)
Date: Fri, 20 Oct 2006 19:17:42 -0700
> path-MTU gets interesting[1] in the context of an an IPsec gateway
> (i.e. tunnel mode IPsec) and there is definitely variability as to how
> reliably an ICMP will be returned in the case that the MTU is exceeded
>
David Miller writes:
> From: [EMAIL PROTECTED] (Stephen J. Bevan)
> Date: Thu, 19 Oct 2006 19:18:41 -0700
>
> > Pawel Foremski writes:
> > > Secondly, IPsec won't decrease MSS in TCP encapsulated in PPPoE
> > > traffic, for example.
> >
> > Various, commercial, IPsec products decrease
Pawel Foremski writes:
> Consider such an example: our task is to bridge two LANs managed by a
> third-party ISP over a wireless link, with the highest performance possible
> for such medium. The ISP has its clients on one LAN and a PPPoE
> concentrator on the second one. Because the ISP doesn
Stephen J. Bevan wrote:
> Pawel Foremski writes:
> > Secondly, IPsec won't decrease MSS in TCP encapsulated in PPPoE
> > traffic, for example.
>
> Various, commercial, IPsec products decrease the MSS for TCP
> encapsulated in PPPoE. I've not checked the Linux 2.6 IPsec code to
> see if it does
On Thursday, 19 October 2006 05:57, Stephen J. Bevan wrote:
> And if the packets come out of order i.e. you get a packet with a new
> key followed by a packet with the old key?
As IV from invalid frames are saved ccrypt will synchronize anyway, but I was
wrong in one aspect - in current implement
From: [EMAIL PROTECTED] (Stephen J. Bevan)
Date: Thu, 19 Oct 2006 19:18:41 -0700
> Pawel Foremski writes:
> > Secondly, IPsec won't decrease MSS in TCP encapsulated in PPPoE
> > traffic, for example.
>
> Various, commercial, IPsec products decrease the MSS for TCP
> encapsulated in PPPoE. I'v
Pawel Foremski writes:
> First, ccrypts task is to secure Ethernet, not IP.
Understood, but the vast majority of traffic running over Ethernet
that a user cares about is IP and so IPsec does the job. Obviously
IPsec cannot handle non-IP traffic but the question is what non-IP
traffic do users wa
Stephen J. Bevan wrote:
> Dawid Ciezarkiewicz writes:
> > It enforces to use upper level encryption with internal
> > fragmentation which is problem because of more more frames that
> > those bridges have to handle, bigger traffic etc.
>
> Where did the fragmentation come from? If you are sen
Dawid Ciezarkiewicz writes:
> You're right. I'll add such documentation. For now - short version: as a
> company dealing with wifi regularly we often come to a problem - using wifi
> bridges with strengths like price, "CE included", easy integration, good
> bandwidth, distance etc. - that th
On Wednesday, 18 October 2006 11:15, Dawid Ciezarkiewicz wrote:
> > * Given your desire not to change the size of the payload you have no
> > space for MAC. This makes it easier (but by no means easy) to alter
> > the payload in such a way that it is still decrypted and considered
> > valid
On Wednesday, 18 October 2006 12:16, David Miller wrote:
> From: Dawid Ciezarkiewicz <[EMAIL PROTECTED]>
> Date: Wed, 18 Oct 2006 11:51:46 +0200
>
> > I've tried to put ccrypt handlers as close to hardware xmit and recv as
> > possible so local reorder doesn't matter. Medium doesn't reorder frame
From: Dawid Ciezarkiewicz <[EMAIL PROTECTED]>
Date: Wed, 18 Oct 2006 11:51:46 +0200
> I've tried to put ccrypt handlers as close to hardware xmit and recv as
> possible so local reorder doesn't matter. Medium doesn't reorder frames and
> switches, bridges shouldn't do that neither (but as Stephe
On Wednesday, 18 October 2006 05:25, David Miller wrote:
> From: [EMAIL PROTECTED] (Stephen J. Bevan)
> Date: Tue, 17 Oct 2006 20:21:46 -0700
>
> > * You write "frames will be delivered in order, so on the other side
> > IV can be always in sync."
>
> In fact, in addition to your comments, Linu
On Wednesday, 18 October 2006 05:21, you wrote:
> Dawid Ciezarkiewicz writes:
> > I'd be thankful for your opinions about that idea. Please forgive me any
> > nuances that I didn't know about.
>
> * I suggest extending the documentation with some motivating examples
> of why someone would wan
From: [EMAIL PROTECTED] (Stephen J. Bevan)
Date: Tue, 17 Oct 2006 20:21:46 -0700
> * You write "frames will be delivered in order, so on the other side
> IV can be always in sync."
In fact, in addition to your comments, Linux can reorder packets
locally within the system even within traffic for
Dawid Ciezarkiewicz writes:
> I'd be thankful for your opinions about that idea. Please forgive me any
> nuances that I didn't know about.
* I suggest extending the documentation with some motivating examples
of why someone would want to use this rather than IPsec for IP
and/or in what scen
On Sunday, 15 October 2006 23:35, you wrote:
> > Hi,
> > I'd be thankful for your opinions about that idea. Please forgive me any
> > nuances that I didn't know about.
>
> This limits the system to only talking to one other system on the same
> link. I guess you could have per-MAC keys and asso
On Sun, 15 Oct 2006, Dawid Ciezarkiewicz wrote:
> Hi,
> I'd be thankful for your opinions about that idea. Please forgive me any
> nuances that I didn't know about.
This limits the system to only talking to one other system on the same
link. I guess you could have per-MAC keys and associate th
Hi,
I'd be thankful for your opinions about that idea. Please forgive me any
nuances that I didn't know about.
diff --git a/Documentation/networking/ccrypt.txt
b/Documentation/networking/ccrypt.txt
new file mode 100644
index 000..8e46f1e
--- /dev/null
+++ b/Documentation/networking/ccrypt.
23 matches
Mail list logo
