Re: Receiving route with metric 0
Am all the more confused now :) > > > > In pre-RFC1058 implementations the sender increments the metric, so a > > directly-connected route's metric is 1 on the wire. > > > > In post-RFC1058 implementations the receiver increments the metric, so > > a directly-connected route's metric is 0 on the wire. > > > > In both cases, the metric in a reciever's database one hop away is 1. Lets say we have A -- B. A is pre-RFC1058 and B is post RFC 1058. A sends a directly connected route as 1. B increments this by 1, and thus stores it as 2. > > You appear to have it backwards. As it says in the section you quoted, > >"These two viewpoints result in identical update messages being >sent." > > Either approach results in messages with metric 1. The metrics on the Hmmm .. not sure. A post 1058 implementation would send a metric 0 for a directly connected route, assuming that the other end would increment the value and things would work out fine. Thanks, Glen
Re: Clueless anti-virus products/vendors (was Re: Sober)
On Dec 6, 2005, at 2:15 PM, Todd Vierling wrote: On Tue, 6 Dec 2005, Douglas Otis wrote: Holding at the data phase does usually avoid the need for a DSN, but this technique may require some added (less than elegant) operations depending upon where the scan engine exists within the email stream. Not my problem. I don't need or want, and should not be hammered with, virus "warnings" sent to forged addresses -- ever. They are unsolicited (I didn't request it, and definitely don't want it), bulk (automated upon receipt of viruses by the offending server), e- mail... thus UBE. I know of no cases where a malware related DSN would be generated by our products, nevertheless, DSNs are not Unsolicited Bulk Email. Generated virus "warnings" must not go to a known forged sender, or to a sender for which the forgery status is unknown. If you cannot *guarantee* that the address in MAIL FROM:<> is correct, and cannot reject at SMTP time, your only options are to quarantine, discard, or allow delivery. Do not send a DSN; do not pass Go; do not collect US$200. Not all email is rejected within the SMTP session. You are changing requirements for recipients that scan incoming messages for malware. Fault them for returning content or not including a null bounce- address. No one can guarantee an email-address within the bounce- address is valid, furthermore a DSN could be desired even for cases where an authorization scheme fails. Why create corner cases? There is always BATV to clean-up spoofed bounce-addresses in the meantime. And other methods (DK, SPF, SID, choose your poison). However, if the server cannot verify that the MAIL FROM:<> is not forged with reasonable certainty, the server should not send a DSN, period. Otherwise, it's a direct contributor to the UBE problem. DomainKeys and Sender-ID can not validate the bounce-address or the DSN. Even with an SPF failure, a DSN should still be sent, as SPF fails in several scenarios, and false positives are never 0%. BATV offers a unilateral option that can effectively discard spoofed bounce-addresses. When the AV software provides the DSN with a null bounce-address, BATV works as advertised. -Doug
Re: Receiving route with metric 0
Stephen Stuart wrote: I am a little confused here. You yourself say that a valid metric starts from 1, then how come 0 be valid for a directly connected route. Are you saying that seeing a RIP metric of 0 on the wire is valid? A metric of 0 from a host would mean that the host itself is the endpoint for the route. See the discussion in section 2 of RFC1058. RFC1058 says: 3.6. Compatibility The protocol described in this document is intended to interoperate with routed and other existing implementations of RIP. However, a different viewpoint is adopted about when to increment the metric than was used in most previous implementations. Using the previous perspective, the internal routing table has a metric of 0 for all directly-connected networks. The cost (which is always 1) is added to the metric when the route is sent in an update message. By contrast, in this document directly-connected networks appear in the internal routing table with metrics equal to their costs; the metrics are not necessarily 1. In this document, the cost is added to the metrics when routes are received in update messages. Metrics from the routing table are sent in update messages without change (unless modified by split horizon). These two viewpoints result in identical update messages being sent. Metrics in the routing table differ by a constant one in the two descriptions. Thus, there is no difference in effect. The change was made because the new description makes it easier to handle situations where different metrics are used on directly-attached networks. Implementations that only support network costs of one need not change to match the new style of presentation. However, they must follow the description given in this document in all other ways. In other words: In pre-RFC1058 implementations the sender increments the metric, so a directly-connected route's metric is 1 on the wire. In post-RFC1058 implementations the receiver increments the metric, so a directly-connected route's metric is 0 on the wire. In both cases, the metric in a reciever's database one hop away is 1. You appear to have it backwards. As it says in the section you quoted, "These two viewpoints result in identical update messages being sent." Either approach results in messages with metric 1. The metrics on the internal routing tables of the machines differ in the two cases. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Clueless anti-virus products/vendors (was Re: Sober)
On Tue, 6 Dec 2005, Douglas Otis wrote: > > > A less than elegant solution as an alternative to deleting the message, is > > > to hold the data phase pending the scan. > > > > Contrary to your vision of this option, it is not only elegant; it happens > > to be the *correct* thing to do. > > Holding at the data phase does usually avoid the need for a DSN, but this > technique may require some added (less than elegant) operations depending upon > where the scan engine exists within the email stream. Not my problem. I don't need or want, and should not be hammered with, virus "warnings" sent to forged addresses -- ever. They are unsolicited (I didn't request it, and definitely don't want it), bulk (automated upon receipt of viruses by the offending server), e-mail... thus UBE. It's up to the server operator to choose how to handle virus protection in the mail system, without generating any mail whatsoever to forged or unknown-if-it-is-forged senders. > It would seem that when a DSN is required, as a > general practice, the DSN should not include message content. > This should at least thwart this vector being used to spread > malware and spam. Preventing the spread of a virus seems key. I, frankly, don't care about the issue of whether or not a "warning" message includes the virus that triggered it; you've missed the point. I care about the fact that these "warnings" are UBE, at levels that have been peaking above those of direct spam from what I can see. Generated virus "warnings" must not go to a known forged sender, or to a sender for which the forgery status is unknown. If you cannot *guarantee* that the address in MAIL FROM:<> is correct, and cannot reject at SMTP time, your only options are to quarantine, discard, or allow delivery. Do not send a DSN; do not pass Go; do not collect US$200. > There is always BATV to clean-up spoofed bounce-addresses in the meantime. And other methods (DK, SPF, SID, choose your poison). However, if the server cannot verify that the MAIL FROM:<> is not forged with reasonable certainty, the server should not send a DSN, period. Otherwise, it's a direct contributor to the UBE problem. -- -- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Clueless anti-virus products/vendors (was Re: Sober)
On Dec 6, 2005, at 8:19 AM, Todd Vierling wrote: On Mon, 5 Dec 2005, Douglas Otis wrote: A less than elegant solution as an alternative to deleting the message, is to hold the data phase pending the scan. Contrary to your vision of this option, it is not only elegant; it happens to be the *correct* thing to do. Holding at the data phase does usually avoid the need for a DSN, but this technique may require some added (less than elegant) operations depending upon where the scan engine exists within the email stream. Waiting for the scan to complete adds stack overhead (assuming a good black-hole list is being used). Albeit small, there is never 0% false detections of malware. It would seem that when a DSN is required, as a general practice, the DSN should not include message content. This should at least thwart this vector being used to spread malware and spam. Preventing the spread of a virus seems key. There is always BATV to clean-up spoofed bounce-addresses in the meantime. -Doug
RE: QoS for ADSL customers
Somebody else emailed me privately link for L7 filtering with linux (its all experimental and requires custom linux patches for now): http://l7-filter.sourceforge.net/L7-HOWTO-Netfilter Also in previous post it was supposed to be: For ebtables it is http://ebtables.sourceforge.net (this is needed if you want security when building custom linux bridge) On Tue, 6 Dec 2005, Ejay Hire wrote: There are quite a few modules for iptables that will reach up to Layer 7, including several specifically for file sharing applications... And one really nifty one that makes non-passive ftp work through NAT. These are "action" modules - they receive the data when it matches particular netfilter rules and then do something in place where you could have accept or reject. But for L7 filtering you need module that can be used in place of "source" or "destination" rules. Yes it is possible to build those with linux (like ipset - see ipset.netfilter.org - its pretty cool), but I've not seen ones for L7 classification - at least not public open source ... The place to find more about iptable is http://www.netfilter.org For iptables it is http://ebtables.sourceforge.net (this one you need only if you're building custom linux bridge). -- William Leibzon Elan Networks [EMAIL PROTECTED]
RE: QoS for ADSL customers
On Tue, 6 Dec 2005, Ejay Hire wrote: There are quite a few modules for iptables that will reach up to Layer 7, including several specifically for file sharing applications... And one really nifty one that makes non-passive ftp work through NAT. These are "action" modules - they receive the data when it matches particular netfilter rules and then do something in place where you could have accept or reject. But for L7 filtering you need module that can be used in place of "source" or "destination" rules. Yes it is possible to build those with linux (like ipset - see ipset.netfilter.org - its pretty cool), but I've not seen ones for L7 classification - at least not public open source ... The place to find more about iptable is http://www.netfilter.org For iptables it is http://ebtables.sourceforge.net (this one you need only if you're building custom linux bridge). -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: Clueless anti-virus products/vendors (was Re: Sober)
On Mon, 5 Dec 2005, Douglas Otis wrote: > A less than elegant solution as an alternative to deleting the message, is > to hold the data phase pending the scan. Contrary to your vision of this option, it is not only elegant; it happens to be the *correct* thing to do. Dropping the message on the floor is arguably stretching the bounds of RFC2821. If a message is going to be dropped because of a policy (such as a worm/virus flag), you really should be rejecting after DATA with a RFC1893 5.7.x extended result code. > Another solution would be not returning message content within a DSN. If you're still sending to a forged address, how is this not still UBE...? -- -- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
RE: QoS for ADSL customers
There are quite a few modules for iptables that will reach up to Layer 7, including several specifically for file sharing applications... And one really nifty one that makes non-passive ftp work through NAT. -e > -Original Message- > From: william(at)elan.net [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 06, 2005 10:50 AM > To: Joe Shen > Cc: Ejay Hire; 'Kim Onnel'; 'NANGO' > Subject: RE: QoS for ADSL customers > > > On Wed, 7 Dec 2005, Joe Shen wrote: > > > Could IPtables control traffic with inspecting layer7 > > information? > > Not layer 7. IPtables works on L3 & L4 (and another similar system > for linux called ebtables provides filtering at L2) but it can > be used for setting up qos depending on where from (and to) the > traffic is going and what port is being used. > > For layer7 filtering on linux you need protocol proxies, and you > can use iptables to redirect all http traffic from subnet to squid > (although its not designed to be a filter, it can be used to > implement L7 filtering for http, but I'm not sure it can be used > for prioritization though). > > > As someone suggested, bandwidth allocation could be > > done with TCP protocol control ( ACK dropping or so); > > How can we do that? NBAR only limit the bandwidth, and > > to our experience with cisco7609 it cost a lot of cpu > > time! > > > > Where can I find QoS experiemnt result and sample > > configuration of ERX14xx? > > > > Joe > > > > > > --- Ejay Hire <[EMAIL PROTECTED]> wrote: > > > >> > >> Hello. > >> > >> Going back to your original question, how to keep > >> from > >> saturating the network with residential users using > >> bittorrent/edonkey et al, while suffocating business > >> customers. Here goes. > >> > >> Netfilter/IpTables (and a slew of commercial > >> products I'm > >> sure) has a Layer 7 traffic classifier, meaning it > >> can > >> identify specific file transfer applications and set > >> a > >> DiffServ bit. This means it can tell between a real > >> http > >> request and a edonkey transfer, even if they are > >> both using > >> http. It also has rate-limiting capability. So... > >> If you > >> pass all of the traffic destined for your DSL > >> customers > >> through an iptables box (single point of failure) > >> then you > >> can classify and rate-limit the downstream rate on a > >> per-application basis. > >> > >> Fwiw, if you are using diffserv bits, you could push > >> the > >> rate-limits down to the router with a qos policy in > >> it > >> instead of doing it all in the iptables box. > >> > >> References on this.. The netfilter website (for > >> classification info) and the Linux advanced router > >> tools > >> (LART) (qos info/rate limiting) > >> > >> -e > >> > >> > >>> -Original Message- > >>> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] > >> On > >>> Behalf Of Kim Onnel > >>> Sent: Thursday, December 01, 2005 3:26 AM > >>> To: NANGO > >>> Subject: Re: QoS for ADSL customers > >>> > >>> Can any one please suggest to me any commercial or > >> none > >>> solution to cap the download stream traffic, our > >> upstream > >>> will not recieve marked traffic from us, so what > >> can be > >> done ? > >>> > >>> > >>> On 11/29/05, Kim Onnel <[EMAIL PROTECTED]> > >> wrote: > >>> > >>> Hello everyone, > >>> > >>> We have Juniper ERX as BRAS for ADSL, its GigE > >>> interface is on an old Cisco 3508 switch with an > >> old IOS, > >> its > >>> gateway to the internet is a 7609, our transit > >> internet > >> links > >>> terminate on GigaE, Flexwan on the 7600 > >>> > >>> The links are now almost always fully utilized, > >> we > >> want > >>> to do some QoS to cap our ADSL downstream, to give > >> room > >> for > >>> the Corp. customers traffic to flow without pain. > >>> > >>> I'm here to collect ideas, comments, advises and > >>> experiences for such situations. > >>> > >>> Our humble approach was to collect some p2p ports > >> and > >>> police traffic to these ports, but the traffic > >> wasnt much, > >> > >>> one other thing is rate-limiting per ADSL > >> customers IPs, > >> but > >>> that wasnt supported by management, so we thought > >> of > >> matching > >>> ADSL www traffic and doing exceed action is > >> transmit, and > >>> police other IP traffic. > >>> > >>> Doing so on the ERX wasnt a nice experience, so > >> we're > >>> trying to do it on the cisco. > >>> > >>> Thanks >
RE: QoS for ADSL customers
On Wed, 7 Dec 2005, Joe Shen wrote: Could IPtables control traffic with inspecting layer7 information? Not layer 7. IPtables works on L3 & L4 (and another similar system for linux called ebtables provides filtering at L2) but it can be used for setting up qos depending on where from (and to) the traffic is going and what port is being used. For layer7 filtering on linux you need protocol proxies, and you can use iptables to redirect all http traffic from subnet to squid (although its not designed to be a filter, it can be used to implement L7 filtering for http, but I'm not sure it can be used for prioritization though). As someone suggested, bandwidth allocation could be done with TCP protocol control ( ACK dropping or so); How can we do that? NBAR only limit the bandwidth, and to our experience with cisco7609 it cost a lot of cpu time! Where can I find QoS experiemnt result and sample configuration of ERX14xx? Joe --- Ejay Hire <[EMAIL PROTECTED]> wrote: Hello. Going back to your original question, how to keep from saturating the network with residential users using bittorrent/edonkey et al, while suffocating business customers. Here goes. Netfilter/IpTables (and a slew of commercial products I'm sure) has a Layer 7 traffic classifier, meaning it can identify specific file transfer applications and set a DiffServ bit. This means it can tell between a real http request and a edonkey transfer, even if they are both using http. It also has rate-limiting capability. So... If you pass all of the traffic destined for your DSL customers through an iptables box (single point of failure) then you can classify and rate-limit the downstream rate on a per-application basis. Fwiw, if you are using diffserv bits, you could push the rate-limits down to the router with a qos policy in it instead of doing it all in the iptables box. References on this.. The netfilter website (for classification info) and the Linux advanced router tools (LART) (qos info/rate limiting) -e -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kim Onnel Sent: Thursday, December 01, 2005 3:26 AM To: NANGO Subject: Re: QoS for ADSL customers Can any one please suggest to me any commercial or none solution to cap the download stream traffic, our upstream will not recieve marked traffic from us, so what can be done ? On 11/29/05, Kim Onnel <[EMAIL PROTECTED]> wrote: Hello everyone, We have Juniper ERX as BRAS for ADSL, its GigE interface is on an old Cisco 3508 switch with an old IOS, its gateway to the internet is a 7609, our transit internet links terminate on GigaE, Flexwan on the 7600 The links are now almost always fully utilized, we want to do some QoS to cap our ADSL downstream, to give room for the Corp. customers traffic to flow without pain. I'm here to collect ideas, comments, advises and experiences for such situations. Our humble approach was to collect some p2p ports and police traffic to these ports, but the traffic wasnt much, one other thing is rate-limiting per ADSL customers IPs, but that wasnt supported by management, so we thought of matching ADSL www traffic and doing exceed action is transmit, and police other IP traffic. Doing so on the ERX wasnt a nice experience, so we're trying to do it on the cisco. Thanks
RE: QoS for ADSL customers
Could IPtables control traffic with inspecting layer7 information? As someone suggested, bandwidth allocation could be done with TCP protocol control ( ACK dropping or so); How can we do that? NBAR only limit the bandwidth, and to our experience with cisco7609 it cost a lot of cpu time! Where can I find QoS experiemnt result and sample configuration of ERX14xx? Joe --- Ejay Hire <[EMAIL PROTECTED]> wrote: > > Hello. > > Going back to your original question, how to keep > from > saturating the network with residential users using > bittorrent/edonkey et al, while suffocating business > customers. Here goes. > > Netfilter/IpTables (and a slew of commercial > products I'm > sure) has a Layer 7 traffic classifier, meaning it > can > identify specific file transfer applications and set > a > DiffServ bit. This means it can tell between a real > http > request and a edonkey transfer, even if they are > both using > http. It also has rate-limiting capability. So... > If you > pass all of the traffic destined for your DSL > customers > through an iptables box (single point of failure) > then you > can classify and rate-limit the downstream rate on a > per-application basis. > > Fwiw, if you are using diffserv bits, you could push > the > rate-limits down to the router with a qos policy in > it > instead of doing it all in the iptables box. > > References on this.. The netfilter website (for > classification info) and the Linux advanced router > tools > (LART) (qos info/rate limiting) > > -e > > > > -Original Message- > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On > > Behalf Of Kim Onnel > > Sent: Thursday, December 01, 2005 3:26 AM > > To: NANGO > > Subject: Re: QoS for ADSL customers > > > > Can any one please suggest to me any commercial or > none > > solution to cap the download stream traffic, our > upstream > > will not recieve marked traffic from us, so what > can be > done ? > > > > > > On 11/29/05, Kim Onnel <[EMAIL PROTECTED]> > wrote: > > > > Hello everyone, > > > > We have Juniper ERX as BRAS for ADSL, its GigE > > interface is on an old Cisco 3508 switch with an > old IOS, > its > > gateway to the internet is a 7609, our transit > internet > links > > terminate on GigaE, Flexwan on the 7600 > > > > The links are now almost always fully utilized, > we > want > > to do some QoS to cap our ADSL downstream, to give > room > for > > the Corp. customers traffic to flow without pain. > > > > I'm here to collect ideas, comments, advises and > > experiences for such situations. > > > > Our humble approach was to collect some p2p ports > and > > police traffic to these ports, but the traffic > wasnt much, > > > one other thing is rate-limiting per ADSL > customers IPs, > but > > that wasnt supported by management, so we thought > of > matching > > ADSL www traffic and doing exceed action is > transmit, and > > police other IP traffic. > > > > Doing so on the ERX wasnt a nice experience, so > we're > > trying to do it on the cisco. > > > > Thanks > > > > > > > > __ Do you Yahoo!? New and Improved Yahoo! Mail - 1GB free storage! http://sg.whatsnew.mail.yahoo.com
Bogon Filters Removal REQ, 124/7, 126/8
Dear colleagues, This is a resend of APNIC message issued Feb this year, many of you have not removed the filters creating problems for many networks in Australia and other APNIC covered countries, as the below mentioned 'near future' has been well underway for some couple of months. It would be appreciated if you could act on this notice at your very earliest convenience if you suspect you are a guilty party :) Thanks in advance. N Subject: [APNIC Members] [Apnic-announce] APNIC new IPv4 addresses Date: Fri, 4 Feb 2005 16:28:07 +1000 (EST) Dear colleagues APNIC received IPv4 address blocks 124/7 and 126/8 from IANA in January 2005 and will be making allocations from these ranges in the near future. This announcement is being made for the information of the Internet community so that network configurations such as routing filters may be updated as appropriate. For more information on the resources administered by APNIC, see: http://www.apnic.net/db/ranges.html
