Re: [RFC] wrr (weighted round-robin) bonding
On Thursday, 19 October 2006 21:04, Andy Gospodarek wrote: It would seem to me that extending an existing mode would be more desirable than adding yet another mode to worry about. I don't even like the fact that there are as many as there are, but I understand why they are there. Ack. I will probably update wrr bonding patch to replace rr mode. I recently extended rr mode to allow an additional parameter called that rr_repeat that would allow someone to send more than a single frame out of each device before moving to the next one. It seemed this could be helpful when dealing with switches that constantly re-learned source MAC addresses. Network performance would suffer whenever rr_repeat was 1, but box performance might be better if there weren't so many locks taken. Thanks. I'll consider adding such functionality. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Ethernet Cheap Cryptography
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 implementation each reorder will cost two frames, not one. This could be possibly reduced to only one, but I must find a time to investigate that more. If the keying is done manually an attacker won't know when the keys are changed. However, if keying is coordinated over the same link via a protocol (as is done with IKE for IPsec) then the attacker can see (or at least guess) the packets carrying the keying protcol thus know re-keying is going to occur. Simple random delay should do the trick. For completness there are also switches that :- * take notice of the TOS/DiffServ bits in an IP header and will re-order based on them Looks like a good reason to change frame type field so it does not look like IP packet. * will re-order frames due to redundancy, load-balancing, spanning-tree changes ... etc. In summary - using ccrypt with switches may lead to problems. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] wrr (weighted round-robin) bonding
On Friday, 20 October 2006 21:53, Jay Vosburgh wrote: Dawid Ciezarkiewicz [EMAIL PROTECTED] wrote: On Thursday, 19 October 2006 21:04, Andy Gospodarek wrote: It would seem to me that extending an existing mode would be more desirable than adding yet another mode to worry about. I don't even like the fact that there are as many as there are, but I understand why they are there. Ack. I will probably update wrr bonding patch to replace rr mode. Also, if acceptance into the mainline is your ultimate goal, the ioctl control interface will be a very difficult sell. You'd want to look into some other control mechanism, most likely an additional sysfs entry. Oh. I'm quite puzzled here. What is current policy? I'd like sysfs interfaces better than ioctl - they are much cleaner etc. - but I thought ioctl will be better here because current bonding control uses ioctl and extending it is much simpler. More generally: should I use sysfs always when adding anything to kernel and use it even when extending older functionality? If wrr bonding have chances for inclusion into mainline I'll do any necessary changes to let it meet requirements. I'd like to know if functionality from Andy's patch is desired to be a part of such round-robin bonding extension. I think I could easily integrate it with wrr. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Ethernet Cheap Cryptography
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 want to use this rather than IPsec for IP and/or in what scenarios you'd envisage someone wanting to encrypt ARP, PPPoE, ... etc. Perhaps, you can somehow mesh it with 802.1x to provide link-level encryption to augment 802.1x link-level authentication? 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 those devices regularly have max eth mtu 1500, not much cpu power and are often so feature-less that there are many problems with good traffic security. 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. We think that solution like ccrypt will be far more secure and simple - and allows to maximize bandwidth and packet per second rate. * Your implementation allows the key to be changed but not in a way that allows both sides to do so without disrupting traffic i.e. you don't have something akin to IKE phase2 re-keying. Without that then if someone can sniff the traffic long enough they are going to get a big sample of data to try and crack the keys with. Well - ccrypt allows to change keys without disrupting traffic. It works like this: first new ccrypt_rx alg:key pair is added. After that ccrypt_rx will still use old alg:key, but all unmatched frames will be challenged against new one too. Then as soon as possible ccrypt_tx should have that new alg:key pair added. When ccrypt_rx gets new frame sent by new alg:key it will not match old alg:key, but will match new one. Receiver will switch then and from now on it will use only new pair. This allows key switching without loosing any frames. It should be done quickly, since when in key transition state all invalid/spoofed frames have double cpu impact on receiver. Shouldn't be a problem because attacker should have no clue about when key is being switched. As device ccrypt_rx and tx are independent traffic encryption can use independent keys in both traffic directions. And because they use pairs of alg:key, in each change: algorithm, key and key length can be changed at once. AFAIK attacker have no way to tell where such change occurs nor what are parameters of current alg:key. The idea is to change keys regularly on both sides with userspace tools - like ssh on separate vlan, or even simpler static key rotation algorithms or something like it. This should allow secure alg:key switching with about any frequency. I hope this will make cracking keys hard enough for attacker that it will not even try. Integrity security is more difficult (and possibly weaker) part of ccrypt. * You write frames will be delivered in order, so on the other side IV can be always in sync. If any switches between the two linux boxes are running any kind of link aggregation then you can't guarantee that the frames will be delivered in order. IEEE 802.3ad requires that packets belonging to the same session travel down the same port to avoid re-ordering but implementations vary as to whether they actually guarantee it or not since most higher level protcols can survive some re-ordering. I was not aware of that. Thanks. I will add this info to documentation. There is nothing actually I can do about that in the form that ccrypt is mean to be now. * 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. Could you explain it more? I don't understand. You mean MAC as ... ? * For the same reason as above you don't have a sequence number. This combined with the lack of MAC weakens the defense against replay attacks i.e. where third party captures a packet and then re-sends it at a later time. The fact that IVs must be in sync for the packet to be accepted makes it harder for an attacker but since they know how the IV is calculated they know what message to look for before replaying a packet. Maybe because of previous one I don't clearly understand the mechanisms. Please - if you could explain it more - that knowledge would be very useful, and I could put it into the docs too. * A variation of the above is that the attacker doesn't care about injecting packets per se, rather they use the above to cause packet loss by causing the receiver to update its IV based on a replayed packet thereby causing the next real
Re: [RFC] Ethernet Cheap Cryptography
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, Linux can reorder packets locally within the system even within traffic for the same link. Any technology which absolutely requires in order packet delivery isn't going to work very well. 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 Stephen J. Bevan said this may not be always true). - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Ethernet Cheap Cryptography
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 frames and switches, bridges shouldn't do that neither (but as Stephen J. Bevan said this may not be always true). You can put it all the way in netif_receive_skb() and you still can see reordering of receive packets on an SMP system. Thanks for pointing that out. As every frame reorder will cost only one real frame to by lost I need to investigate this issue and get more real testing in such environments. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Ethernet Cheap Cryptography
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. Could you explain it more? I don't understand. You mean MAC as ... ? Oh. Sorry. You mean message authentication code. Well - ccrypt have to live without it. From the start I knew that integrity will be the weakest point of ccrypt. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] wrr (weighted round-robin) bonding
On Monday, 16 October 2006 23:30, Andy Gospodarek wrote: On Mon, Oct 16, 2006 at 09:07:57PM +0200, Dawid Ciezarkiewicz wrote: Before getting into the technical bits of the patch, what's the reason for wanting to do this, and why is this rather complex manual weight assignment better than an automatic system based on, e.g., link speed of the slaves? In short: It was designed as a solution for wireless links bonding - where link quality can change rather quickly in time. By using wrr bonding, userspace tools can measure current bandwidth and change bonding slave weights in realtime. Since this is so similar to mode 0, it would seem there would be a way to extend it rather than creating yet another mode that is so similar. What would be the reason not to enhance that mode? In fact - as default weight is being set to 1, without changing it wrr bonding mode works like plain round-robin one. But it have little more overhead (recharging tokens), and code is a bit more complicated. I was not sure if some tools could assume that in mode 0 all interfaces work with same weights and because of that behave strange with this patch in use. It was written as a solution for some problem, and I'm still not sure if such change will always be patch to linux kernel or may some day go into mainline. For compatibility I've decided to have those modes separated. Because of that I haven't replaced mode 0. If this patch will be considered useful, and my concerns are not a problem - I'd like to replace 0 mode if possible. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] wrr (weighted round-robin) bonding
This patch is little thinner then the previous one. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] wrr (weighted round-robin) bonding
On Monday, 16 October 2006 20:21, Dawid Ciezarkiewicz wrote:
This patch is little thinner then the previous one.
I'm sorry for that. I've just ... nevermind. Here goes the patch.
Should I post patch for ifenslave here, too?
diff -Nur linux-2.6.17.orig/Documentation/networking/bonding.txt
linux-2.6.17/Documentation/networking/bonding.txt
--- linux-2.6.17.orig/Documentation/networking/bonding.txt 2006-06-18
03:49:35.0 +0200
+++ linux-2.6.17/Documentation/networking/bonding.txt 2006-07-28
15:47:55.0 +0200
@@ -398,6 +398,19 @@
swapped with the new curr_active_slave that was
chosen.
+ weighted-rr or 7
+
+ Weighted round-robin bonding. In this mode bonding
+ interface will use weights assigned to it's slaves.
+
+ Each slave can have weight assigned via ioctl (ifenslave).
+ These values will be used at the start of each cycle.
+ Each slave will have token counter restored to it's weight.
+ Then using round-robin mechanism those tokens are used
+ to pay for emitted frames. When all token counters are
+ zeroed - new cycle begins.
+
+
primary
A string (eth0, eth2, etc) specifying which slave is the
diff -Nur linux-2.6.17.orig/drivers/net/bonding/bond_main.c
linux-2.6.17/drivers/net/bonding/bond_main.c
--- linux-2.6.17.orig/drivers/net/bonding/bond_main.c 2006-06-18
03:49:35.0 +0200
+++ linux-2.6.17/drivers/net/bonding/bond_main.c2006-07-28
15:31:44.0 +0200
@@ -115,7 +115,7 @@
MODULE_PARM_DESC(mode, Mode of operation : 0 for balance-rr,
1 for active-backup, 2 for balance-xor,
3 for broadcast, 4 for 802.3ad, 5 for balance-tlb,
- 6 for balance-alb);
+ 6 for balance-alb, 7 for weighted-rr);
module_param(primary, charp, 0);
MODULE_PARM_DESC(primary, Primary network device to use);
module_param(lacp_rate, charp, 0);
@@ -162,6 +162,7 @@
{ 802.3ad, BOND_MODE_8023AD},
{ balance-tlb, BOND_MODE_TLB},
{ balance-alb, BOND_MODE_ALB},
+{ weighted-rr, BOND_MODE_WEIGHTED_RR},
{ NULL, -1},
};
@@ -194,6 +195,8 @@
return transmit load balancing;
case BOND_MODE_ALB:
return adaptive load balancing;
+ case BOND_MODE_WEIGHTED_RR:
+ return weighted round robin (weighted-rr);
default:
return unknown;
}
@@ -1198,6 +1201,24 @@
return 0;
}
+int bond_set_weight(struct net_device *bond_dev, struct net_device *slave_dev,
+ u16 weight)
+{
+ struct slave* slave;
+ slave = bond_get_slave_by_dev(bond_dev-priv, slave_dev);
+ if (!slave) {
+ return -EINVAL;
+ }
+
+ slave-weight = weight;
+
+ if (weight) {
+ slave-link = BOND_LINK_UP;
+ slave-state = BOND_STATE_ACTIVE;
+ }
+ return 0;
+}
+
#define BOND_INTERSECT_FEATURES \
(NETIF_F_SG|NETIF_F_IP_CSUM|NETIF_F_NO_CSUM|NETIF_F_HW_CSUM|\
NETIF_F_TSO|NETIF_F_UFO)
@@ -1336,6 +1352,9 @@
*/
new_slave-original_flags = slave_dev-flags;
+ /* slave default weight = 1 */
+ new_slave-weight = 1;
+
/*
* Save slave's original (permanent) mac address for modes
* that need it, and for restoring it upon release, and then
@@ -3601,7 +3620,10 @@
}
down_write((bonding_rwsem));
- slave_dev = dev_get_by_name(ifr-ifr_slave);
+ if (cmd != SIOCBONDSETWEIGHT)
+ slave_dev = dev_get_by_name(ifr-ifr_slave);
+ else
+ slave_dev = dev_get_by_name(ifr-ifr_weight_slave);
dprintk(slave_dev=%p: \n, slave_dev);
@@ -3626,6 +3648,9 @@
case SIOCBONDCHANGEACTIVE:
res = bond_ioctl_change_active(bond_dev, slave_dev);
break;
+ case SIOCBONDSETWEIGHT:
+ res = bond_set_weight(bond_dev, slave_dev,
ifr-ifr_weight_weight);
+ break;
default:
res = -EOPNOTSUPP;
}
@@ -3881,6 +3906,67 @@
return 0;
}
+static int bond_xmit_weighted_rr(struct sk_buff *skb, struct net_device
*bond_dev)
+{
+ struct bonding *bond = bond_dev-priv;
+ struct slave *slave, *start_at;
+ int i;
+ int res = 1;
+ int were_weight_tokens_recharged = 0;
+
+ read_lock(bond-lock);
+
+ if (!BOND_IS_OK(bond)) {
+ goto out;
+ }
+
+ read_lock(bond-curr_slave_lock);
+ slave = start_at = bond-curr_active_slave;
+ read_unlock(bond-curr_slave_lock);
+
+ if (!slave) {
+ goto out;
+ }
+
+try_send:
+ bond_for_each_slave_from(bond, slave, i
Re: [RFC] wrr (weighted round-robin) bonding
On Monday, 16 October 2006 20:50, you wrote: Dawid Ciezarkiewicz [EMAIL PROTECTED] wrote: [...] +weighted-rr or 7 + +Weighted round-robin bonding. In this mode bonding +interface will use weights assigned to it's slaves. + +Each slave can have weight assigned via ioctl (ifenslave). +These values will be used at the start of each cycle. +Each slave will have token counter restored to it's weight. +Then using round-robin mechanism those tokens are used +to pay for emitted frames. When all token counters are +zeroed - new cycle begins. Before getting into the technical bits of the patch, what's the reason for wanting to do this, and why is this rather complex manual weight assignment better than an automatic system based on, e.g., link speed of the slaves? In short: It was designed as a solution for wireless links bonding - where link quality can change rather quickly in time. By using wrr bonding, userspace tools can measure current bandwidth and change bonding slave weights in realtime. It was written for Lintrack, and you can read about it's usage here: http://lintrack.org/index.php/about/advantage - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] Ethernet Cheap Cryptography
Foremski [EMAIL PROTECTED].
+Implementation details and implementation itself was written by
+Dawid Ciezarkiewicz [EMAIL PROTECTED]. Both working in ASN team.
+
+Ccrypt was written as a part of the Lintrack project.
+http://lintrack.org
diff --git a/include/linux/ccrypt.h b/include/linux/ccrypt.h
new file mode 100644
index 000..96f1ad6
--- /dev/null
+++ b/include/linux/ccrypt.h
@@ -0,0 +1,56 @@
+/*
+ * Cheap crypt (ccrypt).
+ * (C) 2006 Dawid Ciezarkiewicz [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifdef __KERNEL__
+#ifndef __CCRYPT_H__
+#define __CCRYPT_H__
+#ifdef CONFIG_NETDEV_CCRYPT
+
+#include linux/crypto.h
+
+struct ccrypt_rx
+{
+ /* tfms[0] - new key */
+ /* tfms[1] - old key */
+ struct crypto_tfm* tfms[2];
+
+ /* [key][0] = iv from last good received packet */
+ /* [key][1] = iv from last received packet */
+ u8* last_recv_iv[2][2];
+
+ /* are last_recv_iv[key][0] and [key][1] equal? */
+ u8 last_recv_iv_matched[2];
+
+ /* should receiver use reversed order of keys
+* until sender starts using new key? */
+ u8 after_switch;
+};
+
+
+struct ccrypt_tx
+{
+ struct crypto_tfm* tfm;
+ u8* last_sent_iv;
+};
+
+struct sk_buff;
+struct class_device;
+struct net_device;
+
+int ccrypt_encrypt(struct sk_buff **pskb);
+int ccrypt_decrypt(struct sk_buff **pskb);
+ssize_t ccrypt_rx_store(struct class_device *dev, const char *buf, size_t len);
+ssize_t ccrypt_tx_store(struct class_device *dev, const char *buf, size_t len);
+ssize_t ccrypt_rx_show(struct class_device *dev, char *buf);
+ssize_t ccrypt_tx_show(struct class_device *dev, char *buf);
+void ccrypt_tx_reset(struct net_device* dev);
+void ccrypt_rx_reset(struct net_device* dev);
+#endif /* CONFIG_NETDEV_CCRYPT */
+#endif /* __CCRYPT_H__ */
+#endif /* __KERNEL__ */
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 50a4719..30daed3 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -38,6 +38,11 @@ #include linux/device.h
#include linux/percpu.h
#include linux/dmaengine.h
+#ifdef CONFIG_NETDEV_CCRYPT
+struct ccrypt_rx;
+struct ccrypt_tx;
+#endif /* CONFIG_NETDEV_CCRYPT */
+
struct divert_blk;
struct vlan_group;
struct ethtool_ops;
@@ -521,6 +526,14 @@ #ifdef CONFIG_NET_DIVERT
struct divert_blk *divert;
#endif /* CONFIG_NET_DIVERT */
+#ifdef CONFIG_NETDEV_CCRYPT
+ /* 0 means - don't use */
+ struct ccrypt_rx* ccrypt_rx;
+ spinlock_t ccrypt_rx_lock;
+ struct ccrypt_tx* ccrypt_tx;
+ spinlock_t ccrypt_tx_lock;
+#endif /* CONFIG_NETDEV_CCRYPT */
+
/* class/net/name entry */
struct class_device class_dev;
/* space for optional statistics and wireless sysfs groups */
diff --git a/net/Kconfig b/net/Kconfig
index 4959a4e..ccf6cd8 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -73,6 +73,16 @@ config NETWORK_SECMARK
to nfmark, but designated for security purposes.
If you are unsure how to answer this question, answer N.
+config NETDEV_CCRYPT
+ bool Ethernet Cheap Crypt
+ depends on CRYPTO
+ help
+ This enables cheap cryptography in layer2. For more info read
+ Documentation/networking/ccrypt.txt . This is experimental
+ functionality and should be used with care.
+
+ If you are unsure how to answer this question, answer N.
+
menuconfig NETFILTER
bool Network packet filtering (replaces ipchains)
---help---
diff --git a/net/core/Makefile b/net/core/Makefile
index 2645ba4..1c05def 100644
--- a/net/core/Makefile
+++ b/net/core/Makefile
@@ -12,6 +12,7 @@ obj-y += dev.o ethtool.o dev_mcast
obj-$(CONFIG_XFRM) += flow.o
obj-$(CONFIG_SYSFS) += net-sysfs.o
+obj-$(CONFIG_NETDEV_CCRYPT) += ccrypt.o
obj-$(CONFIG_NET_DIVERT) += dv.o
obj-$(CONFIG_NET_PKTGEN) += pktgen.o
obj-$(CONFIG_WIRELESS_EXT) += wireless.o
diff --git a/net/core/ccrypt.c b/net/core/ccrypt.c
new file mode 100644
index 000..c03ad11
--- /dev/null
+++ b/net/core/ccrypt.c
@@ -0,0 +1,941 @@
+/*
+ * Ethernet Cheap Crypt (ccrypt).
+ * (C) 2006 Dawid Ciezarkiewicz [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/ccrypt.h
+
+#include linux/if_arp.h
+#include linux/if_pppox.h
+#include linux/if_vlan.h
+#include linux/scatterlist.h
+
+#include linux/crypto.h
+#include linux/module.h
+#include linux/skbuff.h
+#include linux/ip.h
+#include net/checksum.h
+
+#define to_net_dev(class) container_of(class, struct net_device, class_dev)
+
+/**
+ * Allocate ccrypt_rx.
+ */
+struct ccrypt_rx* ccrypt_rx_alloc(void) {
+ struct ccrypt_rx* new_cc = kmalloc
Re: [RFC] Ethernet Cheap Cryptography
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 associate the crypto info with neighbor cache entries. The idea is to use vlan and macvlan devices to separate encrypted traffic - as you can just encrypt vlan device. Other than that - yes ccrypt was considered as solution for point-to-point links. Likely need a cryptographer to review the protocol -- blindly using the first block of every encrypted packet as the IV smells problematic, for example. Cryptographic part needs attention. I'm not a cryptographer and no cryptographer have checked the idea or code. And yes - this is little problematic, but I think the solution is good enough - there is little chance to inject valid upper level packet, and even if such event occur - there is no chance that can carry valid hostile information. The magic function is is_decoded_buffer_valid, which - using upper level info - will just drop packets that weren't encrypted correctly. There are little chances that spoofed frame after decryption will look like good packet - for IPv4 I estimate them to be much less than 1 to 256 * 256 * 32 (2097152) and this can be rather easily improved. Injected packets that will not pass such validation will not change stored IV, so transmition will not be affected. And even when such frame will pass - it will probable consist of garbages - the only effect will be using bad IV in the next encryption - so next good frame will be dropped. If ccrypt will be considered reasonable I was thinking about kernel warnings on spoofing tries detection, using simple bad frames counters. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][ebtables][vlan] ebt_vlan_t target
On Thursday, 6 July 2006 13:15, Ingo Oeser wrote: First of all: You should not implemented --vlan-target. Always return EBT_CONTINUE. That saves a lot of (duplicated) code (you can express the same using some more rules) while keeping the same flexibility level. Rules for transforming/mangling and decision rules should be seperate. OK. I've been doing everything looking how ebt_mark.c is written. I thought about dropping it (iptables has nothing like this and works), but I havent't been sure if I should. diff -Nur linux-2.6.17.orig/net/bridge/netfilter/Kconfig linux-2.6.17/net/bridge/netfilter/Kconfig --- linux-2.6.17.orig/net/bridge/netfilter/Kconfig 2006-06-18 03:49:35.0 +0200 +++ linux-2.6.17/net/bridge/netfilter/Kconfig 2006-06-28 20:48:27.0 +0200 @@ -165,6 +165,15 @@ To compile it as a module, choose M here. If unsure, say N. +config BRIDGE_EBT_VLAN_T + tristate ebt: vlan target support + depends on BRIDGE_NF_EBTABLES + help + This option adds the vlan target. + + To compile it as a module, choose M here. If unsure, say N. + + Please put your nice explanations to change vlan ids in fly from your email here. OK. I cannot comment on rest of the patch and hope other people will do :-) I hope they do, too. Thanks. :) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
