using IPv6 address block across multiple locations
Hello, Please advice what is the best practice to use IPv6 address block across distributed locations. Recently we obtained our PI /48 from RIPE. The idea was to assign partial slices from this block to different locations (we have currently 3 offices in Europe and 2 in USA). All locations are interconnected with static VPNs. Each location is supposed to establish BGP session with local ISP. Partial prefix /56 + aggregate /48 (with long AS PATH) are to be announced by each office. The problem we ran across is that ISP in US does not wish to accept prefixes longer then /48 from us. Need your advice: is this normal to distribute /48 by /56 parts across locations or should we obtain separate /48 for each of them? Or maybe we need /32 that can be split into multiple /48? Anyway we are not ISP so /48 looks quite reasonable and sufficient for all our needs. Thank you. Dmitry Cherkasov
Re: using IPv6 address block across multiple locations
On Mon, 31 Oct 2011, Dmitry Cherkasov wrote: Need your advice: is this normal to distribute /48 by /56 parts across locations or should we obtain separate /48 for each of them? Or maybe we need /32 that can be split into multiple /48? Anyway we are not ISP so /48 looks quite reasonable and sufficient for all our needs. Don't expect anyone to accept less than /48, so in your setup you need a /48 per site. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: using IPv6 address block across multiple locations
Couldn't you also advertise the /48 from all the sites, if you're willing to sort things out over the inter-site VPNs?--Richard On Mon, Oct 31, 2011 at 4:37 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: On Mon, 31 Oct 2011, Dmitry Cherkasov wrote: Need your advice: is this normal to distribute /48 by /56 parts across locations or should we obtain separate /48 for each of them? Or maybe we need /32 that can be split into multiple /48? Anyway we are not ISP so /48 looks quite reasonable and sufficient for all our needs. Don't expect anyone to accept less than /48, so in your setup you need a /48 per site. -- Mikael Abrahamsson email: swm...@swm.pp.se
Re: using IPv6 address block across multiple locations
On 2011-10-31 08:56 , Dmitry Cherkasov wrote: Hello, Please advice what is the best practice to use IPv6 address block across distributed locations. You go to multiple RIRs and get multiple prefixes. Heck, you apparently can even get multiple disjunct prefixes from the same RIR. There went the whole idea of aggregation Greets, Jeroen (Note though that some entities who actually got disjunct prefixes are quite large and will be putting quite a number of hosts behind those prefixes, thus the usage/prefix ratio is quite high and likely worthy of a routing slot)
Re: using IPv6 address block across multiple locations
Not sure about RIPE, but under ARIN, you would qualify for a /44 (or larger if you have more than 12 sites), out of which you could announce the /48s independently and as an aggregate, as you wish to do. -Randy - Original Message - Hello, Please advice what is the best practice to use IPv6 address block across distributed locations. Recently we obtained our PI /48 from RIPE. The idea was to assign partial slices from this block to different locations (we have currently 3 offices in Europe and 2 in USA). All locations are interconnected with static VPNs. Each location is supposed to establish BGP session with local ISP. Partial prefix /56 + aggregate /48 (with long AS PATH) are to be announced by each office. The problem we ran across is that ISP in US does not wish to accept prefixes longer then /48 from us. Need your advice: is this normal to distribute /48 by /56 parts across locations or should we obtain separate /48 for each of them? Or maybe we need /32 that can be split into multiple /48? Anyway we are not ISP so /48 looks quite reasonable and sufficient for all our needs. Thank you. Dmitry Cherkasov
Re: using IPv6 address block across multiple locations
Ideally, you should put a /48 at each location. Owen On Oct 31, 2011, at 12:56 AM, Dmitry Cherkasov wrote: Hello, Please advice what is the best practice to use IPv6 address block across distributed locations. Recently we obtained our PI /48 from RIPE. The idea was to assign partial slices from this block to different locations (we have currently 3 offices in Europe and 2 in USA). All locations are interconnected with static VPNs. Each location is supposed to establish BGP session with local ISP. Partial prefix /56 + aggregate /48 (with long AS PATH) are to be announced by each office. The problem we ran across is that ISP in US does not wish to accept prefixes longer then /48 from us. Need your advice: is this normal to distribute /48 by /56 parts across locations or should we obtain separate /48 for each of them? Or maybe we need /32 that can be split into multiple /48? Anyway we are not ISP so /48 looks quite reasonable and sufficient for all our needs. Thank you. Dmitry Cherkasov
RE: Outgoing SMTP Servers
Bill, Responses in-line... -Original Message- From: Bill Stewart [mailto:nonobvi...@gmail.com] Sent: Friday, October 28, 2011 6:22 PM To: nanog@nanog.org Cc: Brian Johnson Subject: Re: Outgoing SMTP Servers snip I've got a strong preference for ISPs to run a Block-25-by-default/Enable-when-asked. As a purist, I'd prefer to have Internet connections that are actually Internet connections, and if you want to run email on a Linux box at home or have an Arduino in your refrigerator email the grocery when you're out of milk, you should be able to, and if some meddling kid at an ISP wants to block it, they should get off your lawn. In practice, of course, somewhere between 99.9% and 99.999% of all home MTAs aren't Linux boxes or Macs, they're zombie spambots on home PCs, or occasional driveby wifi spammers or other pests, and not only should outgoing mail be blocked, but the user should be notified and the connection should probably be put into some kind of quarantined access. This is, of course, exactly why this blocking is done. But that's for Port 25 - the Port 25 blocking by ISPs has largely pushed Email Service Providers to use other protocols such as 587 for mail submission from an MUA to the MTA, or webmail instead, and it's really bad practice for ISPs to interfere with that. In some cases they'll still be sending spam, but that's the MTA's job to filter out, and if they don't, they'll end up on a bunch of RBLs. (And generally they'll be trying to keep their mail clean themselves - if the MTA providers were spammers, they wouldn't need to go to the trouble of having actual residential users as customers when they could mass-produce it cheaper directly.) For clarity it's really bad for ISPs to block ports other than 25 for the purposes of mail flow control... correct? I would not block submission ports, specifically 587. More specifically, the only port I will block would be 25. The RFC actually says to use the submission port for the MUA to MTA anyways. RFC 5068 is definitive on this issue. Also read RFC 4409 and its predecessors. My take on this is that it IS best practice to have users use the submission port (587) for mail submission from the MUA to an MTA. Call me a liar! :) - Brian
Re: using IPv6 address block across multiple locations
On Mon, 31 Oct 2011, Dmitry Cherkasov wrote: The problem we ran across is that ISP in US does not wish to accept prefixes longer then /48 from us. Need your advice: is this normal to distribute /48 by /56 parts across locations or should we obtain separate /48 for each of them? Or maybe we need /32 that can be split into multiple /48? Anyway we are not ISP so /48 looks quite reasonable and sufficient for all our needs. Think of a /48 the same way you'd use a /24 of IPv4 space in a multi-homed design. /48 is the smallest v6 block that you can reasonably expect to be globally reachable. Many providers will not accept anything smaller, unless it's from one of their own blocks, in which case it will likely get aggregated into their larger prefix. jms
Re: Google+ now available for Google Apps domains
On Oct 27, 2011, at 9:46 PM, Justin Seabrook-Rocha wrote: Once that tool is complete, you should be able to merge/migrate your gmail G+ account to your Google Apps account. You can already do so with most of the numerous other Google properties. Keep in mind that if you want to publicly post on Google+ using your Google Apps account, you will need to change your account name to conform with Google's definition of something that looks kind of like the thing on your government photo ID.
Hands and Eyes for London and Amsterdam
Hi : Looking for some recommendation on Hands and Eyes to aid in setting up gear in datacenters located in Amsterdam and London. Exceptional quality of workmanship a must. Thanks Mike
RE: Hands and Eyes for London and Amsterdam
For London: http://www.netsumo.com/ -- Leigh Porter -Original Message- From: Mike Rae [mailto:mike@sjrb.ca] Sent: 31 October 2011 16:26 To: nanog@nanog.org Subject: Hands and Eyes for London and Amsterdam Hi : Looking for some recommendation on Hands and Eyes to aid in setting up gear in datacenters located in Amsterdam and London. Exceptional quality of workmanship a must. Thanks Mike __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: using IPv6 address block across multiple locations
On 10/31/11 03:43 , Jeroen Massar wrote: On 2011-10-31 08:56 , Dmitry Cherkasov wrote: Hello, Please advice what is the best practice to use IPv6 address block across distributed locations. You go to multiple RIRs and get multiple prefixes. Heck, you apparently can even get multiple disjunct prefixes from the same RIR. There went the whole idea of aggregation or you could just get an aggregateable block of the appropiate size from one RIR and deaggregate it as necessary which should be the normal course of action... Greets, Jeroen (Note though that some entities who actually got disjunct prefixes are quite large and will be putting quite a number of hosts behind those prefixes, thus the usage/prefix ratio is quite high and likely worthy of a routing slot)
Re: Outgoing SMTP Servers
Dave CROCKER wrote: On 10/30/2011 8:36 PM, Brian Johnson wrote: So you support filtering end-user outbound SMTP sessions as this is a means to prevent misuse of the Commons*. Correct? If it is acceptable to have the receiving SMTP server at one end of a connection do filtering -- and it is -- then why wouldn't it be acceptable to have filtering done at the source end of that SMTP connection? As soon as we step upstream this way, stepping up earlier still is merely a question of efficacy and efficiency. I've often wondered the same thing as to what the resistance is to outbound filtering is. I can think of a few possibilities: 1) cost of filtering 2) false positives 3) really _not_ wanting to know about abuse Given the cost of incoming filtering, I'd think that outbound filtering would be down in the noise. On the other hand, getting support blowback for false positives seems plausible, but probably no worse than blowback from false positives incoming. So, #3 -- assuming my list is exhaustive which it probably isn't -- seems like a real possibility. Especially when you consider that it opens a can of worms of now that we know we have a likely bot, what do we with it, and how much will that cost? Mike
Re: using IPv6 address block across multiple locations
On Oct 31, 2011, at 12:30 49PM, Joel jaeggli wrote: On 10/31/11 03:43 , Jeroen Massar wrote: On 2011-10-31 08:56 , Dmitry Cherkasov wrote: Hello, Please advice what is the best practice to use IPv6 address block across distributed locations. You go to multiple RIRs and get multiple prefixes. Heck, you apparently can even get multiple disjunct prefixes from the same RIR. There went the whole idea of aggregation or you could just get an aggregateable block of the appropiate size from one RIR and deaggregate it as necessary which should be the normal course of action... One important question: if data for one of your locations were to be sent from somewhere that is closer (as the packets fly) to another, would you prefer that it be sent over your VPN or over the open Internet? The latter may be cheaper for you, since you don't have to pay for that bandwidth; the former may be more secure if your VPN is encrypted. To send stuff only over the open Internet in this situation, use a separate /48 for each location. To send stuff only over your VPN, put everything in a single /44 or so and advertise only it. Advertising the /44 and having each location advertising its own /48 within that /44 will usually cause the traffic to go over the open Internet, with your VPN as backup in case of reachability problems if some ISPs won't carry the longer /48s because of their own policies. --Steve Bellovin, https://www.cs.columbia.edu/~smb
Re: Outgoing SMTP Servers
On 10/31/2011 11:48 AM, Michael Thomas wrote: I've often wondered the same thing as to what the resistance is to outbound filtering is. I can think of a few possibilities: 1) cost of filtering 2) false positives 3) really _not_ wanting to know about abuse On the other hand, you have 1) cost of tracking 2) support costs handling infections It's really an range from easiest and cost effective to doing it right. I personally run hybrid. There are areas that are near impossible to track; this is especially true for wide area wireless/cellular/NAT areas. I always recommend my customers block tcp/25, even to the local smarthosts. Use 587 and authentication to support better tracking. It's a hack, though, as it doesn't stop other abuses and it won't fix the underlying root cause. In locations that support ease of tracking, using a mixture of feedback loops with proper support is usually the proper way. This allows notification and fixing of the root cause. In our case, we recommend quick suspensions to demonstrate to customer how seriously we take the problem, and then we point out that the sending of spam/scanning is only the easier to detect symptoms. It is unlikely we'll notice if they have a keylogger as well. Finally, when architecture allows it, dynamic profiles with ACL support allowing a default of tcp/25 blocked, and easy to find and click removal of an account from tcp/25 blocking, combined with ACL monitoring, flagging, and notification by support staff is probably the ultimate in ideal scenarios. Combined with a % of traffic mirrored into a tunnel to an IDS which monitors for things such as network scanning or known signatures outbound, it makes for a very effective mechanism to assist customers in protecting themselves. I'm personally curious how much traffic is necessary to mirror to properly detect problems. ie, can you get away with 1% or less (GE for each 100GE-200GE of traffic) or if you must cover as much as 10%+. My traffic load is small enough that it doesn't matter, but it's always nice to know how well something might scale. Jack
Re: Google+ now available for Google Apps domains
Possibly not for much longer: http://mashable.com/2011/10/19/google-to-support-pseudonyms/ Regards, Jay On 01/11/2011, at 2:49 AM, Kee Hinckley naz...@somewhere.com wrote: On Oct 27, 2011, at 9:46 PM, Justin Seabrook-Rocha wrote: Once that tool is complete, you should be able to merge/migrate your gmail G+ account to your Google Apps account. You can already do so with most of the numerous other Google properties. Keep in mind that if you want to publicly post on Google+ using your Google Apps account, you will need to change your account name to conform with Google's definition of something that looks kind of like the thing on your government photo ID.
Re: Outgoing SMTP Servers
On: Mon, 31 Oct 2011 09:48:21 -0700, Michael Thomas m...@mtcc.com opined: Dave CROCKER wrote: On 10/30/2011 8:36 PM, Brian Johnson wrote: So you support filtering end-user outbound SMTP sessions as this is a means to prevent misuse of the Commons*. Correct? If it is acceptable to have the receiving SMTP server at one end of a connection do filtering -- and it is -- then why wouldn't it be acceptable to have filtering done at the source end of that SMTP connection? As soon as we step upstream this way, stepping up earlier still is merely a question of efficacy and efficiency. I've often wondered the same thing as to what the resistance is to outbound filtering is. I can think of a few possibilities: 1) cost of filtering 2) false positives 3) really _not_ wanting to know about abuse Given the cost of incoming filtering, I'd think that outbound filtering would be down in the noise. On the other hand, getting support blowback for false positives seems plausible, but probably no worse than blowback from false positives incoming. So, #3 -- assuming my list is exhaustive which it probably isn't -- seems like a real possibility. Especially when you consider that it opens a can of worms of now that we know we have a likely bot, what do we with it, and how much will that cost? There is an at-least-somewhat-valid argument against outbound filtering. to wit, various receiving systems may have different policies on what is/ is-not 'acceptable' traffic. They have a better idea of what is acceptable to the recipients (their users), than the originating MTA operator does. An originating system cannot accomodate that diversity of opinions _without_ getting input from all prospective recipients. And it is, of course, 'not practical' for every email recipient to notify every email 'source' network as to what that recpient considers 'acceptable'. wry grin There are only a relative handful of things a _residential_ provider can use to reliably filter outgoing mail. A non-comprehensive list: 1) 'Greylisting' at the origin is as effective at stopping spam as it is at the destination. 2) Checks for certain kinds of standards violations that legitimate mail software does not make. 3) Check for certain kinds of 'lies' in headers -- things that *cannot* occur in legitimate email. 4) 'Rate-limiting' to detect/quarrantine abnormal traffic levels. 5) Tracking SMTP 'MAIL FROM: and the From: (or 'Resent-From:', if present), and quarrantining on abnormal numbers of different putative origins. There's no point in checking source addresses against any DNSBL, for reasons that should be 'obvious'. *GRIN* Further, any sort of content filters prevent customers from _discussing_ scams in e-mail. There is a 'hard' problem in letting the source 'opt out' of such filtering, because an intentional 'bad guy' will request his outgoing mail not be monitored, as well as the person who has a 'legitimate' reason for sending messages that might trip mindless content filters. Statistical note: Out of the last roughly 6,000 pieces of spam seen here, circa 2,700 were caught by checks 2), and 3) above, and another circa 2,600 were in character-sets not supported here. Incidentally, spam volume, as seen here, is running a bit _under_ 2/3 of all email, down from a peak of over 95%.
Re: Google+ now available for Google Apps domains
On Oct 31, 2011, at 5:00 PM, Jay Mitchell wrote: Possibly not for much longer: http://mashable.com/2011/10/19/google-to-support-pseudonyms/ Google officially* repudiated that, saying it was nothing new, just their old promise that eventually they plan to offer pseudonym support if they can solve the technical problems. * By officially, I mean that Google+ VP Vic Gundotra commented in Mike Elgan's post that Mike was correct. That's about as official as Google gets when it comes to the policy.
Re: using IPv6 address block across multiple locations
On Mon, 31 Oct 2011 05:39:57 -0400, Richard Barnes richard.bar...@gmail.com wrote: Couldn't you also advertise the /48 from all the sites, if you're willing to sort things out over the inter-site VPNs? If we're talking about a site-to-site IPsec VPN over the internet, then that's a very bad idea. Even if the internet in this case is entirely within the same provider's network. (and it doesn't sound like it is.) --Ricky
Manage an enterprise network? Please fill out my survey - for Science! :-)
Hello! My name is Justine and I am a graduate student at UC Berkeley (http://cs.berkeley.edu/~justine). I'm doing a research project on middlebox appliances such as proxies, WAN optimizers, and firewalls. Middlebox appliances are any networking-related hardware other than routers and switches. I'd like to learn a little bit about how middleboxes are used in real world deployments in enterprises. Vendors often engage in surveys of this type - but the research community knows less than we'd like to about typical concerns in an enterprise network. If you work on network management in an enterprise, I'd love to hear about your experiences through this survey: https://docs.google.com/spreadsheet/viewform?hl=en_USformkey=dHo1NGZ3eU04SlBaSnNsSlBYZGNYSlE6MQ#gid=0 Some promises: (1) If you give me your email address, I will not give it to anyone else, nor will I add you to any annoying mailing lists. (2) If you mention the name of your organization, I will not share it with anyone else. (3) If I publish any data from this, statistics will be reported in aggregate. (4) I will not share the raw data from this survey with anyone other than my advisor, Professor Sylvia Ratnasamy (syl...@eecs.berkeley.edu). Feel free to skip questions and please provide approximate answers if you have them. Finally, to thank you for your time, we'll enter you in to a lottery for a $100 Amazon gift card; we'll select two people to win and contact them on November 16. Thank you! If you have any questions or concerns, please contact me. Justine PS: The survey is here! Don't miss it! https://docs.google.com/spreadsheet/viewform?hl=en_USformkey=dHo1NGZ3eU04SlBaSnNsSlBYZGNYSlE6MQ#gid=0
Re: Outgoing SMTP Servers
Sent from my iPad On Oct 31, 2011, at 1:30 PM, Jack Bates jba...@brightok.net wrote: On 10/31/2011 11:48 AM, Michael Thomas wrote: I've often wondered the same thing as to what the resistance is to outbound filtering is. I can think of a few possibilities: 1) cost of filtering 2) false positives 3) really _not_ wanting to know about abuse On the other hand, you have 1) cost of tracking 2) support costs handling infections It's really an range from easiest and cost effective to doing it right. I personally run hybrid. There are areas that are near impossible to track; this is especially true for wide area wireless/cellular/NAT areas. I always recommend my customers block tcp/25, even to the local smarthosts. Use 587 and authentication to support better tracking. It's a hack, though, as it doesn't stop other abuses and it won't fix the underlying root cause. Let me know when u can fix the root causes. The two I know of: 1. Bad actors 2. Clueless users In locations that support ease of tracking, using a mixture of feedback loops with proper support is usually the proper way. This allows notification and fixing of the root cause. In our case, we recommend quick suspensions to demonstrate to customer how seriously we take the problem, and then we point out that the sending of spam/scanning is only the easier to detect symptoms. It is unlikely we'll notice if they have a keylogger as well. Still not the real root cause, but close. ;) Largely in agreement otherwise. - Brian
Re: Outgoing SMTP Servers
Sent from my iPad On Oct 31, 2011, at 4:17 PM, Robert Bonomi bon...@mail.r-bonomi.com snip There is an at-least-somewhat-valid argument against outbound filtering. to wit, various receiving systems may have different policies on what is/ is-not 'acceptable' traffic. They have a better idea of what is acceptable to the recipients (their users), than the originating MTA operator does. An originating system cannot accomodate that diversity of opinions _without_ getting input from all prospective recipients. And it is, of course, 'not practical' for every email recipient to notify every email 'source' network as to what that recpient considers 'acceptable'. wry grin This is not plausible. It also has nothing to do with a network owner protecting his network from his own users. There are only a relative handful of things a _residential_ provider can use to reliably filter outgoing mail. A non-comprehensive list: 1) 'Greylisting' at the origin is as effective at stopping spam as it is at the destination. 2) Checks for certain kinds of standards violations that legitimate mail software does not make. 3) Check for certain kinds of 'lies' in headers -- things that *cannot* occur in legitimate email. 4) 'Rate-limiting' to detect/quarrantine abnormal traffic levels. 5) Tracking SMTP 'MAIL FROM: and the From: (or 'Resent-From:', if present), and quarrantining on abnormal numbers of different putative origins. There's no point in checking source addresses against any DNSBL, for reasons that should be 'obvious'. *GRIN* Further, any sort of content filters prevent customers from _discussing_ scams in e-mail. There is a 'hard' problem in letting the source 'opt out' of such filtering, because an intentional 'bad guy' will request his outgoing mail not be monitored, as well as the person who has a 'legitimate' reason for sending messages that might trip mindless content filters. Statistical note: Out of the last roughly 6,000 pieces of spam seen here, circa 2,700 were caught by checks 2), and 3) above, and another circa 2,600 were in character-sets not supported here. Incidentally, spam volume, as seen here, is running a bit _under_ 2/3 of all email, down from a peak of over 95%. This misses the point of the thread which is not filtering. It is port 25 blocking. Statistically all of he problems exist on TCP port 25. This is why the filtering is largely effective. - Brian
Re: Manage an enterprise network? Please fill out my survey - for Science! :-)
Hello Justine, I find it interesting, to say the least, that all of the communication that you have about a Berkeley research program while your email came from washington.edu? Thanks, 'Ayo . Success is getting what you want, happiness is wanting what you get - Ingrid Bergman ... the sky is too low to be my limit Sent from my iPhone On Oct 31, 2011, at 6:48 PM, Justine Sherry just...@cs.washington.edu wrote: Hello! My name is Justine and I am a graduate student at UC Berkeley (http://cs.berkeley.edu/~justine). I'm doing a research project on middlebox appliances such as proxies, WAN optimizers, and firewalls. Middlebox appliances are any networking-related hardware other than routers and switches. I'd like to learn a little bit about how middleboxes are used in real world deployments in enterprises. Vendors often engage in surveys of this type - but the research community knows less than we'd like to about typical concerns in an enterprise network. If you work on network management in an enterprise, I'd love to hear about your experiences through this survey: https://docs.google.com/spreadsheet/viewform?hl=en_USformkey=dHo1NGZ3eU04SlBaSnNsSlBYZGNYSlE6MQ#gid=0 Some promises: (1) If you give me your email address, I will not give it to anyone else, nor will I add you to any annoying mailing lists. (2) If you mention the name of your organization, I will not share it with anyone else. (3) If I publish any data from this, statistics will be reported in aggregate. (4) I will not share the raw data from this survey with anyone other than my advisor, Professor Sylvia Ratnasamy (syl...@eecs.berkeley.edu). Feel free to skip questions and please provide approximate answers if you have them. Finally, to thank you for your time, we'll enter you in to a lottery for a $100 Amazon gift card; we'll select two people to win and contact them on November 16. Thank you! If you have any questions or concerns, please contact me. Justine PS: The survey is here! Don't miss it! https://docs.google.com/spreadsheet/viewform?hl=en_USformkey=dHo1NGZ3eU04SlBaSnNsSlBYZGNYSlE6MQ#gid=0
Re: Manage an enterprise network? Please fill out my survey - for Science! :-)
A quick look at her web pg shows her undergad @ UWash On Mon, Oct 31, 2011 at 11:23 PM, Adefisayo Adegoke afis...@gmail.com wrote: Hello Justine, I find it interesting, to say the least, that all of the communication that you have about a Berkeley research program while your email came from washington.edu? Thanks, 'Ayo . Success is getting what you want, happiness is wanting what you get - Ingrid Bergman ... the sky is too low to be my limit Sent from my iPhone On Oct 31, 2011, at 6:48 PM, Justine Sherry just...@cs.washington.edu wrote: Hello! My name is Justine and I am a graduate student at UC Berkeley (http://cs.berkeley.edu/~justine). I'm doing a research project on middlebox appliances such as proxies, WAN optimizers, and firewalls. Middlebox appliances are any networking-related hardware other than routers and switches. I'd like to learn a little bit about how middleboxes are used in real world deployments in enterprises. Vendors often engage in surveys of this type - but the research community knows less than we'd like to about typical concerns in an enterprise network. If you work on network management in an enterprise, I'd love to hear about your experiences through this survey: https://docs.google.com/spreadsheet/viewform?hl=en_USformkey=dHo1NGZ3eU04SlBaSnNsSlBYZGNYSlE6MQ#gid=0 Some promises: (1) If you give me your email address, I will not give it to anyone else, nor will I add you to any annoying mailing lists. (2) If you mention the name of your organization, I will not share it with anyone else. (3) If I publish any data from this, statistics will be reported in aggregate. (4) I will not share the raw data from this survey with anyone other than my advisor, Professor Sylvia Ratnasamy (syl...@eecs.berkeley.edu). Feel free to skip questions and please provide approximate answers if you have them. Finally, to thank you for your time, we'll enter you in to a lottery for a $100 Amazon gift card; we'll select two people to win and contact them on November 16. Thank you! If you have any questions or concerns, please contact me. Justine PS: The survey is here! Don't miss it! https://docs.google.com/spreadsheet/viewform?hl=en_USformkey=dHo1NGZ3eU04SlBaSnNsSlBYZGNYSlE6MQ#gid=0
Re: Manage an enterprise network? Please fill out my survey - for Science! :-)
:) I should've guessed that you guys, of all people, would notice the discrepancy. I used to be at the UW; I registered for this list using my UW email address. Rather than re-register in order to be able to post to the list, I just sent from my old email address. The survey is linked from my homepage and the UW affiliation is mentioned: http://www.eecs.berkeley.edu/~justine/ Justine On Mon, Oct 31, 2011 at 19:23, Adefisayo Adegoke afis...@gmail.com wrote: Hello Justine, I find it interesting, to say the least, that all of the communication that you have about a Berkeley research program while your email came from washington.edu? Thanks, 'Ayo . Success is getting what you want, happiness is wanting what you get - Ingrid Bergman ... the sky is too low to be my limit Sent from my iPhone On Oct 31, 2011, at 6:48 PM, Justine Sherry just...@cs.washington.edu wrote: Hello! My name is Justine and I am a graduate student at UC Berkeley (http://cs.berkeley.edu/~justine). I'm doing a research project on middlebox appliances such as proxies, WAN optimizers, and firewalls. Middlebox appliances are any networking-related hardware other than routers and switches. I'd like to learn a little bit about how middleboxes are used in real world deployments in enterprises. Vendors often engage in surveys of this type - but the research community knows less than we'd like to about typical concerns in an enterprise network. If you work on network management in an enterprise, I'd love to hear about your experiences through this survey: https://docs.google.com/spreadsheet/viewform?hl=en_USformkey=dHo1NGZ3eU04SlBaSnNsSlBYZGNYSlE6MQ#gid=0 Some promises: (1) If you give me your email address, I will not give it to anyone else, nor will I add you to any annoying mailing lists. (2) If you mention the name of your organization, I will not share it with anyone else. (3) If I publish any data from this, statistics will be reported in aggregate. (4) I will not share the raw data from this survey with anyone other than my advisor, Professor Sylvia Ratnasamy (syl...@eecs.berkeley.edu). Feel free to skip questions and please provide approximate answers if you have them. Finally, to thank you for your time, we'll enter you in to a lottery for a $100 Amazon gift card; we'll select two people to win and contact them on November 16. Thank you! If you have any questions or concerns, please contact me. Justine PS: The survey is here! Don't miss it! https://docs.google.com/spreadsheet/viewform?hl=en_USformkey=dHo1NGZ3eU04SlBaSnNsSlBYZGNYSlE6MQ#gid=0
RE: Outgoing SMTP Servers
Dave CROCKER [mailto:d...@dcrocker.net] said on Sunday, 30 October, 2011 22:41 On 10/30/2011 8:36 PM, Brian Johnson wrote: So you support filtering end-user outbound SMTP sessions as this is a means to prevent misuse of the Commons*. Correct? If it is acceptable to have the receiving SMTP server at one end of a connection do filtering -- and it is -- then why wouldn't it be acceptable to have filtering done at the source end of that SMTP connection? As soon as we step upstream this way, stepping up earlier still is merely a question of efficacy and efficiency. Actually, if it is my network I have the absolute right to control what comes in and what goes out. If I am a commercial entity and my paying customers like this, then I will make lots of money. If they don't, I will go out of business. Thus for self-interest and survival end-user-networks do not restrict outbound excessively but block inbound with various policies that strike a balance between paying customers going elsewhere and paying customers leaving for less controlled environments, while still making a profit and staying in business. Hence, we end up with the situation that we have. It won't change without either (a) every operator deciding to do the same thing for their own collective best interest (such as blocking outbound TCP/25); or, (b) external fascist forces. And the bit-movers really don't care, since all they do is move bits...and more bits means more money.
Re: Outgoing SMTP Servers
On 10/31/2011 8:12 PM, Brian Johnson wrote: Sent from my iPad On Oct 31, 2011, at 1:30 PM, Jack Batesjba...@brightok.net wrote: On 10/31/2011 11:48 AM, Michael Thomas wrote: I've often wondered the same thing as to what the resistance is to outbound filtering is. I can think of a few possibilities: 1) cost of filtering 2) false positives 3) really _not_ wanting to know about abuse On the other hand, you have 1) cost of tracking 2) support costs handling infections It's really an range from easiest and cost effective to doing it right. I personally run hybrid. There are areas that are near impossible to track; this is especially true for wide area wireless/cellular/NAT areas. I always recommend my customers block tcp/25, even to the local smarthosts. Use 587 and authentication to support better tracking. It's a hack, though, as it doesn't stop other abuses and it won't fix the underlying root cause. Let me know when u can fix the root causes. The two I know of: 1. Bad actors 2. Clueless users While true, from a security viewpoint, the root cause is loss of control over the system involved. Spam, while perhaps the most visible and annoying to others is not my highest concern (We find the number of clueless users direct spamming is miniscule compared to hijacked systems). My concern is that the customer has lost control of their machine and could at that moment be unknowingly giving out critical information. -Jack
Re: Manage an enterprise network? Please fill out my survey - for Science! :-)
On 10/31/11 19:33 , Justine Sherry wrote: :) I should've guessed that you guys, of all people, would notice the discrepancy. I used to be at the UW; I registered for this list using my UW email address. Rather than re-register in order to be able to post to the list, I just sent from my old email address. The survey is linked from my homepage and the UW affiliation is mentioned: http://www.eecs.berkeley.edu/~justine/ I've met Justine and can vouch for her serious, laser-focused interest in middlebox research, and that if she's not really attending Cal then she's bamboozled a whole heap of CS profs over there. But seriously, if you can help her ascertain real middlebox use cases she wants to help improve that segment of networking via useful research, nothing more or less. -Scott Justine On Mon, Oct 31, 2011 at 19:23, Adefisayo Adegokeafis...@gmail.com wrote: Hello Justine, I find it interesting, to say the least, that all of the communication that you have about a Berkeley research program while your email came from washington.edu? Thanks, 'Ayo . Success is getting what you want, happiness is wanting what you get - Ingrid Bergman ... the sky is too low to be my limit Sent from my iPhone On Oct 31, 2011, at 6:48 PM, Justine Sherryjust...@cs.washington.edu wrote: Hello! My name is Justine and I am a graduate student at UC Berkeley (http://cs.berkeley.edu/~justine). I'm doing a research project on middlebox appliances such as proxies, WAN optimizers, and firewalls. Middlebox appliances are any networking-related hardware other than routers and switches. I'd like to learn a little bit about how middleboxes are used in real world deployments in enterprises. Vendors often engage in surveys of this type - but the research community knows less than we'd like to about typical concerns in an enterprise network. If you work on network management in an enterprise, I'd love to hear about your experiences through this survey: https://docs.google.com/spreadsheet/viewform?hl=en_USformkey=dHo1NGZ3eU04SlBaSnNsSlBYZGNYSlE6MQ#gid=0 Some promises: (1) If you give me your email address, I will not give it to anyone else, nor will I add you to any annoying mailing lists. (2) If you mention the name of your organization, I will not share it with anyone else. (3) If I publish any data from this, statistics will be reported in aggregate. (4) I will not share the raw data from this survey with anyone other than my advisor, Professor Sylvia Ratnasamy (syl...@eecs.berkeley.edu). Feel free to skip questions and please provide approximate answers if you have them. Finally, to thank you for your time, we'll enter you in to a lottery for a $100 Amazon gift card; we'll select two people to win and contact them on November 16. Thank you! If you have any questions or concerns, please contact me. Justine PS: The survey is here! Don't miss it! https://docs.google.com/spreadsheet/viewform?hl=en_USformkey=dHo1NGZ3eU04SlBaSnNsSlBYZGNYSlE6MQ#gid=0
Re: Manage an enterprise network? Please fill out my survey - for Science! :-)
On 10/31/2011 11:00 PM, Scott Whyte wrote: But seriously, if you can help her ascertain real middlebox use cases she wants to help improve that segment of networking via useful research, nothing more or less. Would love to see the results, although it definitely is catered more to enterprise than ISP (where many of these are probably used more than in enterprise). It's missing a small datapoint. What types of failures are most likely to occur?(Physical/electrical, Misconfiguration, Overload) Layer-3 Routers -SOFTWARE BUGS! : ) -Jack
Re: Manage an enterprise network? Please fill out my survey - for Science! :-)
On Oct 31, 2011 9:13 PM, Jack Bates jba...@brightok.net wrote: On 10/31/2011 11:00 PM, Scott Whyte wrote: But seriously, if you can help her ascertain real middlebox use cases she wants to help improve that segment of networking via useful research, nothing more or less. Would love to see the results, although it definitely is catered more to enterprise than ISP (where many of these are probably used more than in enterprise). Unfotunately ISPs are deploying many middle boxen, frequently in series, for various reasons...cough cough cgn. Given that these middle box infested ISPs are supposed to be providing internet, that seems like more fertile research grounds, as the definition of internet is starting to shift ...at least imho. Cb It's missing a small datapoint. What types of failures are most likely to occur?(Physical/electrical, Misconfiguration, Overload) Layer-3 Routers -SOFTWARE BUGS! : ) -Jack
Re: Manage an enterprise network? Please fill out my survey - for Science! :-)
On Nov 1, 2011, at 11:44 AM, Cameron Byrne wrote: Unfotunately ISPs are deploying many middle boxen, frequently in series, for various reasons...cough cough cgn. This AusNOG presentation touches upon the topic: http://www.ausnog.net/images/ausnog-05/presentations/7-2-stateofdanger.pdf --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde
