Re: Customer-facing ACLs

[Jo Rhett]

Justin Shore wrote:
I'm assuming everyone uses uRPF at all their edges already so that 
eliminates the need for specific ACEs with ingress/egress network 
verification checks.


ha.  I only wish that was true.

We do filter all customer ports for IPs we believe from them, but darn 
few other providers do.  (as based on my conversations with many 
providers when tracking down attacks from their networks)


That said, we filter nothing else.


Frags are explicitly dropped before any permits.


...?  So you have no real, production sites?

Re: Customer-facing ACLs

[JC Dill]

Doesn't anyone RTFM before posting anymore?

http://mail.google.com/support/bin/answer.py?hl=en&answer=13287

# Configure your client to match the settings below:
Incoming Mail (POP3) Server - requires SSL: pop.gmail.com
Use SSL: Yes
Port: 995
Outgoing Mail (SMTP) Server - requires TLS: 	smtp.gmail.com (use 
authentication)

Use Authentication: Yes
Use STARTTLS: Yes (some clients call this SSL)
Port: 465 or 587

There is no need to use smtp on port 25 with gmail.  configure the 
client according to gmail's instructions and use 465 or 587.


jc


Frank Bulk - iNAME wrote:

Those using Google for SMTP can still use their ISP's SMTP servers for
outbound

Frank

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ang
Kah Yik
Sent: Monday, March 10, 2008 7:40 PM
To: Andy Dills
Cc: nanog@merit.edu
Subject: Re: Customer-facing ACLs


Hi Andy (and all who responded),

Thanks for the heads-up on the redirection on SMTP traffic. I've yet to
see an implementation of it but I agree that it's a possible solution.

As for the issue I raised previously, perhaps corporate users isn't a
good example but what about users of email services such as Gmail and
the like?

RE: Customer-facing ACLs

[Frank Bulk - iNAME]

Those using Google for SMTP can still use their ISP's SMTP servers for
outbound

Frank

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ang
Kah Yik
Sent: Monday, March 10, 2008 7:40 PM
To: Andy Dills
Cc: nanog@merit.edu
Subject: Re: Customer-facing ACLs


Hi Andy (and all who responded),

Thanks for the heads-up on the redirection on SMTP traffic. I've yet to
see an implementation of it but I agree that it's a possible solution.

As for the issue I raised previously, perhaps corporate users isn't a
good example but what about users of email services such as Gmail and
the like?
Some users do use the SMTP service instead of the web interface. But
redirection should do the trick.

And thanks to all who remind me about rfc 2476 - I'm not a mail admin so
I'm not familiar with it but I'll read up on it.

Andy Dills wrote:
> And wouldn't those corporate types require VPN to access the network?
>
> On top of that, most who "block" 25 don't block it but direct it to
> internal mail servers where it can be subjected to limits and filtering.
>
> Andy
>
> ---
> Andy Dills
> Xecunet, Inc.
> www.xecu.net
> 301-682-9972
> ---
>
> For what it's worth, that's what port 587 was created for.

RE: Customer-facing ACLs

[Frank Bulk - iNAME]

We have a two-dozen line long ACL applied to our CMTS and BRAS blocking
Windows and "virus" ports and have never had a complaint or a problem.  We
do have a more sophisticated residential or large-biz customers ask, but
only once has our ACL been the source of a problem and it's only because the
OEM version of the software didn't implement communications the same way as
their branded version.

Frank

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sean
Donelan
Sent: Monday, March 10, 2008 2:30 PM
To: Scott Weeks
Cc: nanog@merit.edu
Subject: Re: Customer-facing ACLs


On Mon, 10 Mar 2008, Scott Weeks wrote:
> The hard part is I now always take over networks that have been in
> operation a long time and enabling these policies can be very painful
> after the fact.  Establishing them when the network is new is a
> different story.

Whatever you decide, whether you know what the policies are or not, there
are always have a set of default network policies.

The question is do you explain to you customers just as carefully what
your default policy doesn't do, as well as what it does.  Do you take
just as much time to carefully explain the risks and what may break to
your customers of allowing that traffic as you would of not allowing that
traffic.

It seems to be very painful whatever decision is made.

Re: Customer-facing ACLs

[Justin Shore]

Ang Kah Yik wrote:


However, considering the number of mobile workers out there who send 
email via their laptops to corporate SMTP servers, won't blocking 
outbound SMTP affect them?


After all, there are also those who frequently move from place to place 
so they're going to have to keep changing SMTP servers every time they 
go to a new place that's on a different ISP.


Thanks for joining the discussion.  Frankly I'd be surprised to find 
many corps with an externally-accessible SMTP server that would accept 
mail on tcp/25.  The only way they'd do it is with SMTP AUTH which 
(hopefully) implies the use of SMTP TLS as well.  I know of very few 
corps that actually do this.  Most of the corps I can think of are 
either running Exchange and utilizing RPC over HTTP, simply point their 
users to their company's webmail server, or require that their users VPN 
back to HQ to access their internal MTA.  The sites that I can think of 
with external user-accessible SMTP daemons are entities with highly 
technical users.  They utilize SMTP AUTH, TLS, and the Mail Submission 
Port on tcp/587.  I'm afraid they are in the minority though.


The MSP port is the best way to get around the blocks with decent MTAs. 
 Your local MTA's support for other non-standard mechanisms for 
relaying mail from untrusted networks may also help with this problem 
(RPC over HTTP).  Other than that I don't think there's enough demand 
for outgoing SMTP from the masses to warrant not blocking it. 
Redirecting generally takes care of that anyway.


Thanks for the input though.  All thoughts are welcome.
 Justin

Re: Customer-facing ACLs

[Adrian Chadd]

I've attempted to summarise the replies I found useful in the Wiki:

http://nanog.cluepon.net/index.php/MailTopics#Customer-Facing_ACLs

My personal observations:

* More information about what networks are doing would be nice!
* More data points about probes/scans/etc would be nice!
* Filtering technologies would be nice for ACLs - not shaping of things
  like BT/YT/etc - stuff like how to deploy per-customer ACLs on
  a variety of tech. I know I've used ACLs in Radius AV pairs in a
  SP environment for DSL aggregation; I've also used similar hackery
  in 802.1x for per-port ethernet ACLs in an Enterprise environment.
  Has anyone rolled out 802.1x style port authentication in a ethernet-
  edge scenario and included ACLs/shaping AV-pairs? Experience/Feedback
  would be great.

Constructive comments appreciated.




Adrian

Re: Customer-facing ACLs

[Christopher Morrow]

On Mon, Mar 10, 2008 at 7:58 PM, Ang Kah Yik <[EMAIL PROTECTED]> wrote:
>
>  Hi Justin (and all others on-list)
>
>  I understand your grounds for blocking outbound SMTP for your customers
>  (especially those on dynamic IP connections).
>  It probably will do good to block infected customers that are spewing
>  spam all over the world.
>
>  However, considering the number of mobile workers out there who send
>  email via their laptops to corporate SMTP servers, won't blocking
>  outbound SMTP affect them?
>

vpns fix this...

>  Since these corporate types (I'm guessing here) are probably unaware of
>  how to change their email client's SMTP configurations, chances are that
>  blocking outbound SMTP will probably cause quite a lot of pain.
>

uunet dialup has blocked port25 in both directions since 2002...
little to no complaints. (well, they may have received complaints
since I left, but... thank John StClair for the work behind that
filtering actually.)

>  After all, there are also those who frequently move from place to place
>  so they're going to have to keep changing SMTP servers every time they
>  go to a new place that's on a different ISP.
>

many config's actually just use WCCP to transparently redirect your
smtp to an authorized SMTP server as Andy Dills points out.

-Chris

Re: Peering with the Internet Alert Registry

[Josh Karlin]

Chris,

That's a good question.  IAR peers that also wish to run PGBGP will transmit
their anomalous routes out of band to the IAR.  This will likely be done via
logs and a simple forwarding script.

Josh



On Mon, Mar 10, 2008 at 4:01 PM, Christopher Morrow <
[EMAIL PROTECTED]> wrote:

> On Mon, Mar 10, 2008 at 11:01 AM, Josh Karlin <[EMAIL PROTECTED]> wrote:
> > All,
> >
> > Some of you are aware of the site for network operators:
> > http://iar.cs.unm.edu/  which has running for two years now.  The
> purpose of
> > the site is to detect and distribute network anomaly information to the
> > network operators that need to know.  The flip side of our proposed
> security
> > system, Pretty Good BGP (PGBGP), lowers the local preference of
> anomalous
> > routes on BGP routers for 24 hours, giving operators time to respond to
> > anomalous routes before they can fully propagate.
> >
>
> does pgbgp toss out alerts/snmp-traps/log-messages when these
> anomalous announcements arrive? if not, how does one know they are
> inside the 24hr window?
>

Re: Customer-facing ACLs

[Sean Donelan]

On Mon, 10 Mar 2008, Scott Weeks wrote:

The default policy is we allow eveything.  It takes no explaining.


If you don't bother to explain to the same customers who you believe 
couldn't figure out how to change the default settings, what the 
risks and how to protect their computers on the Internet, is it any 
wonder that normal user's have such a difficult time being safe on the 
Internet?


I understand the port 25 issue and am reconsidering it for dynamic 
addresses on outbound traffic, but at least one person on NANOG showed 
me a use of that.  Like network engineers at many other companies, I'm 
spread so thin that it's hard to find the time to do work like this and 
I keep putting it on the back burner.  VZ had it completely open and I 
have followed that as we seperated this network from their network, as
I can't take on the extra work of fixing brokenness that would result 
from applying the filter.


Like I said, there is always a default policy whether you know what
that policy is or not.  You probably end up spending the resources on
the front-end or on the back-end.

Implementing source address verification can take years, but if you
never start, you will never finish.

Implementing sanity checks for IP headers can take years, but if you
never start, you will never finish.

Implementing unsolicited/unwanted traffic controls can take years, but
if you never start, you will never finish.

Do you think caller-id/call-blocking/harrassing-call-trace were easy, or
rather they took years of hard work.  Although the technology may change,
people seem to stay the same.  And people seem to be adept at doing the
same stuff with new technology to other people.

Customer-facing ACLs

[mack]

> --
>
> Date: Tue, 11 Mar 2008 07:58:01 +0800
> From: Ang Kah Yik <[EMAIL PROTECTED]>
> Subject: Customer-facing ACLs
>
> Hi Justin (and all others on-list)
>
> I understand your grounds for blocking outbound SMTP for your customers
> (especially those on dynamic IP connections).
> It probably will do good to block infected customers that are spewing
> spam all over the world.
>
> However, considering the number of mobile workers out there who send
> email via their laptops to corporate SMTP servers, won't blocking
> outbound SMTP affect them?
>
> Since these corporate types (I'm guessing here) are probably unaware of
> how to change their email client's SMTP configurations, chances are
> that
> blocking outbound SMTP will probably cause quite a lot of pain.
>
> After all, there are also those who frequently move from place to place
> so they're going to have to keep changing SMTP servers every time they
> go to a new place that's on a different ISP.
>
> Cheers
> - --
> ANG Kah Yik (bangky)
>
> --

One would hope mobile commuters are using something more secure
than just raw SMTP to send e-mail if their network admins have
any sense.  The usual combination requires a POP connection first
or uses a port other than 25 to send.  As a customer my home DSL
service provider (SBC) blocks port 25 by default.  Many firewalls can
be programmed to allow 'related' connections.  Ie. if a POP connection
is opened then allow the SMTP connection.

The real solution is to move to imap or msa (port 587) or the latest
MS exchange protocol (whatever it is).

As for blocking FTP and SSH, it would depend A LOT on your customer base.

As a content provider we do not allow raw NetBios into our network.
Anyone that wants to use remote file sharing to work on their windows server
is encouraged (Whips and Chains if necessary) to use a VPN tunnel.

If you are going to block something, block port 135 both directions.

--
LR Mack McBride
Network Administrator
Alpha Red, Inc.

Re: Customer-facing ACLs

[Ang Kah Yik]

Hi Andy (and all who responded),

Thanks for the heads-up on the redirection on SMTP traffic. I've yet to 
see an implementation of it but I agree that it's a possible solution.


As for the issue I raised previously, perhaps corporate users isn't a 
good example but what about users of email services such as Gmail and 
the like?
Some users do use the SMTP service instead of the web interface. But 
redirection should do the trick.


And thanks to all who remind me about rfc 2476 - I'm not a mail admin so 
I'm not familiar with it but I'll read up on it.


Andy Dills wrote:
And wouldn't those corporate types require VPN to access the network? 

On top of that, most who "block" 25 don't block it but direct it to 
internal mail servers where it can be subjected to limits and filtering.


Andy

---
Andy Dills
Xecunet, Inc.
www.xecu.net
301-682-9972
---
  
For what it's worth, that's what port 587 was created for.

Re: Customer-facing ACLs

[Andy Dills]

On Tue, 11 Mar 2008, Ang Kah Yik wrote:

> 
> Hi Justin (and all others on-list)
> 
> I understand your grounds for blocking outbound SMTP for your customers
> (especially those on dynamic IP connections).
> It probably will do good to block infected customers that are spewing spam all
> over the world.
> 
> However, considering the number of mobile workers out there who send email via
> their laptops to corporate SMTP servers, won't blocking outbound SMTP affect
> them?
> 
> Since these corporate types (I'm guessing here) are probably unaware of how to
> change their email client's SMTP configurations, chances are that blocking
> outbound SMTP will probably cause quite a lot of pain.
> 
> After all, there are also those who frequently move from place to place so
> they're going to have to keep changing SMTP servers every time they go to a
> new place that's on a different ISP.

For what it's worth, that's what port 587 was created for.

And wouldn't those corporate types require VPN to access the network? 

On top of that, most who "block" 25 don't block it but direct it to 
internal mail servers where it can be subjected to limits and filtering.

Andy

---
Andy Dills
Xecunet, Inc.
www.xecu.net
301-682-9972
---

Customer-facing ACLs

[Ang Kah Yik]

Hi Justin (and all others on-list)

I understand your grounds for blocking outbound SMTP for your customers 
(especially those on dynamic IP connections).
It probably will do good to block infected customers that are spewing 
spam all over the world.


However, considering the number of mobile workers out there who send 
email via their laptops to corporate SMTP servers, won't blocking 
outbound SMTP affect them?


Since these corporate types (I'm guessing here) are probably unaware of 
how to change their email client's SMTP configurations, chances are that 
blocking outbound SMTP will probably cause quite a lot of pain.


After all, there are also those who frequently move from place to place 
so they're going to have to keep changing SMTP servers every time they 
go to a new place that's on a different ISP.


Cheers
--
ANG Kah Yik (bangky)

Re: Peering with the Internet Alert Registry

[Christopher Morrow]

On Mon, Mar 10, 2008 at 11:01 AM, Josh Karlin <[EMAIL PROTECTED]> wrote:
> All,
>
> Some of you are aware of the site for network operators:
> http://iar.cs.unm.edu/  which has running for two years now.  The purpose of
> the site is to detect and distribute network anomaly information to the
> network operators that need to know.  The flip side of our proposed security
> system, Pretty Good BGP (PGBGP), lowers the local preference of anomalous
> routes on BGP routers for 24 hours, giving operators time to respond to
> anomalous routes before they can fully propagate.
>

does pgbgp toss out alerts/snmp-traps/log-messages when these
anomalous announcements arrive? if not, how does one know they are
inside the 24hr window?

Re: Customer-facing ACLs

[Scott Weeks]

-- [EMAIL PROTECTED] wrote: --
On Mon, 10 Mar 2008, Scott Weeks wrote:

> The hard part is I now always take over networks that have been in 
> operation a long time and enabling these policies can be very painful 
> after the fact.  Establishing them when the network is new is a 
> different story.

Whatever you decide, whether you know what the policies are or not, there
are always have a set of default network policies.

The question is do you explain to you customers just as carefully what
your default policy doesn't do, as well as what it does.  Do you take
just as much time to carefully explain the risks and what may break to 
your customers of allowing that traffic as you would of not allowing that 
traffic.

It seems to be very painful whatever decision is made.
-



The default policy is we allow eveything.  It takes no explaining.  

I understand the port 25 issue and am reconsidering it for dynamic addresses on 
outbound traffic, but at least one person on NANOG showed me a use of that.  
Like network engineers at many other companies, I'm spread so thin that it's 
hard to find the time to do work like this and I keep putting it on the back 
burner.  VZ had it completely open and I have followed that as we seperated 
this network from their network, as I can't take on the extra work of fixing 
brokenness that would result from applying the filter.

scott

Re: Customer-facing ACLs

[Sean Donelan]

On Mon, 10 Mar 2008, Scott Weeks wrote:
The hard part is I now always take over networks that have been in 
operation a long time and enabling these policies can be very painful 
after the fact.  Establishing them when the network is new is a 
different story.


Whatever you decide, whether you know what the policies are or not, there
are always have a set of default network policies.

The question is do you explain to you customers just as carefully what
your default policy doesn't do, as well as what it does.  Do you take
just as much time to carefully explain the risks and what may break to 
your customers of allowing that traffic as you would of not allowing that 
traffic.


It seems to be very painful whatever decision is made.

Re: Customer-facing ACLs

[Scott Weeks]

Long response with answers inline...

--- [EMAIL PROTECTED] wrote:---
> Might as well do TCP 20, 21 and 23, too.  Woah, that slope's getting slippery!

Depends on how you ask the questions.

How about: Should a statefull firewall be provided for casual broadband 
dynamic Internet access connections by default?  Users may change the 
default settings of the stateful firewall as they choose.
1. Unsolicited inbound (to user LAN) traffic
-

The ultimate answer is: It depends.  :-)  As you know, it depends on your 
network and who your users are.  My experiences are with a global network of 
cold potato routing for high-end enterprises, a 10,000 person university and, 
currently, a state-wide ILEC.  In these networks no, internet access should not 
be closed partially by default and then allowed to be opened by a user.  

Little tutus out in Hana are not going to be able to figure it out when trying 
to use things their keiki on the mainland are telling them to use that're not 
on port 80.  College students are just going to open everything so they don't 
have to worry blockages of the newest, kewlest thing to start up that they want 
to try.  Enterprises want to be in as complete control of their services as 
possible, so perhaps there, if they all have technically adept network folks.



-
Are there LAN-only protocols and other data packets which shouldn't be 
accepted on WAN Internet access links without prior coordination (if 
ever)?
1. Anti-spoofing controls of source addresses
2. Proxy/gratitious ARP, ICMP redirects, DHCP server->client, RIP?
3. "Local" multicast data and broadcasts
4. "Sanity" checks of IP headers (i.e. source==destination,
loopback, etc) which should never appear on the wire
5. Layer 2 non-Internet (non-IP, non-IPv6, non-ARP, non-PPPOE)

Are there some protocols that should have prior coordination when using 
some Internet access types, e.g. dynamic or unauthenticated connections?
1. outbound to off-net SMTP (port 25) instead of MSA (port 587)
2. NetBios over TCP, the exploding Microsoft protocol?
--

The first 1-5...OK, possibly, but that isn't what the person was speaking 
about.  

The second 1-2, no, unless it's VERY clear to your customers upfront.  I used 
to be of the 'second 1-2' opnion, but I've since changed my mind on the kind of 
networks I help operate.  It's funny (in a sick kind of way) how much stuff you 
can break when you filter unless you have the time to do a *very complete* 
traffic analysis over an extended time period.   Folks do all sorts of crazy 
crap that I think they shouldn't do (off-LAN Micro$loth file sharing, for 
example), but are doing and some have done for a long time.  

The hard part is I now always take over networks that have been in operation a 
long time and enabling these policies can be very painful after the fact.  
Establishing them when the network is new is a different story.

scott

ARIN & CAIDA IPv6 Survey

[Member Services]

The American Registry for Internet Numbers (ARIN), in cooperation with 
the Cooperative Association for Internet Data Analysis (CAIDA), is 
conducting a survey to gather data regarding the current and future use 
of IPv6 throughout the ARIN Region. For a complete list of countries go 
to: http://www.arin.net/community/ARINcountries.html  

We encourage all organizations in the ARIN region to participate in the 
survey so we can establish a comprehensive view of present IPv6 
penetration and future plans of IPv6 deployment.  The survey will open 
on 10 March and remain available until noon ET on 24 March. The results 
of the survey will be presented and discussed at the ARIN XXI Public 
Policy and Members Meeting to be held in Denver 6-9 April 2008, and the 
survey data will support ongoing research.


The survey is composed of 20 questions that can be answered in a few 
minutes.  When you complete the survey you will be entered in a drawing 
for prizes. You must provide your contact information to win.  This is a 
secure survey and all data will be presented in summary form only, and 
kept confidential between ARIN and CAIDA.


Please take a few moments to complete the survey located at:

https://www.surveymonkey.com/s.aspx?sm=2x5j2OlJl0cq44iYfQadrw_3d_3d

Regards,

Member Services
American Registry for Internet Numbers (ARIN)

Re: Customer-facing ACLs

[Sean Donelan]

On Fri, 7 Mar 2008, Scott Weeks wrote:

To me there is no question of whether or not you filter traffic for
residential broadband customers.


SBC in my area (Dallas) went from wide open to outbound 25 blocked by
default/opened on request. I think doing the same thing with port 22 would
hardly be an undue burden on users, and would help keep botnets in check.


Might as well do TCP 20, 21 and 23, too.  Woah, that slope's getting slippery!



Depends on how you ask the questions.

How about: Should a statefull firewall be provided for casual broadband 
dynamic Internet access connections by default?  Users may change the 
default settings of the stateful firewall as they choose.

1. Unsolicited inbound (to user LAN) traffic

Are there LAN-only protocols and other data packets which shouldn't be 
accepted on WAN Internet access links without prior coordination (if 
ever)?

1. Anti-spoofing controls of source addresses
2. Proxy/gratitious ARP, ICMP redirects, DHCP server->client, RIP?
3. "Local" multicast data and broadcasts
4. "Sanity" checks of IP headers (i.e. source==destination,
loopback, etc) which should never appear on the wire
5. Layer 2 non-Internet (non-IP, non-IPv6, non-ARP, non-PPPOE)

Are there some protocols that should have prior coordination when using 
some Internet access types, e.g. dynamic or unauthenticated connections?

1. outbound to off-net SMTP (port 25) instead of MSA (port 587)
2. NetBios over TCP, the exploding Microsoft protocol?

Re: Tools to measure TCP connection speed

[Wil Schultz]

A couple of tools I use from time to time are iperf and ttcp. I'll run  
iperf on some host and either run ttcp to it from a router or iperf to  
another host. You can also run ttcp router to router.


-wil

On Mar 10, 2008, at 8:51 AM, Joe Shen wrote:


we do not just want to analyze e2e performance, but to
monitor network performance at IP and TCP layer.

We monitor end-to-end ping with smokeping, but as you
know, ICMP data does not reflect application layer
permance at any time. So, we set up two hosts to
measure TCP permance.

Is there tools like smokeping to monitoring e2e TCP
connecting speed?

Joe




--- "Darden, Patrick S." <[EMAIL PROTECTED]> wrote:




Best way to do it is right after the SYN just count
"one one thousand, two one thousand" until you get
the ACK.  This works best for RFC 1149 traffic, but
is applicable for certain others as well.

I don't know of any automated tool, per se.  You
really couldn't do it *well* on the software side.
I see a few options:

1.  this invalidates itself, but it is easily
doable: get one of those ethernet cards that
includes all stack processing, and write a simple
driver that includes a timing mechanism and a
logger.  It invalidates itself because your
real-life connection speeds would depend on the
actual card you usually use, the OS, etc. ad
nauseum, and you would be bypassing all of those.

2.  if you are using a "free" as in open source OS,
specifically as in Linux or FreeBSD, then you could
write a simple kernel module that could do it.  It
would still be wrong--but depending on your skill it
wouldn't be too wrong.

3.  this might actually work for you.  Check to see
how many total TCP connections your OS can handle,
make sure your TCP timeout is set to the default 15
minutes, then set up a simple perl script that
simply starts a timer, opens sockets as fast as it
can, and when it reaches the total the OS can handle
it lets you know the time passed.  Take that and
divide by total number of connections and you get
the average  It won't be very accurate, but it
will give you some kind of idea.

Please forgive the humor

--Patrick Darden



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Joe Shen
Sent: Monday, March 10, 2008 5:00 AM
To: NANGO
Subject: Tools to measure TCP connection speed



hi,

 is there any tool could measue e2e TCP connection
speed?


 e.g. we want to measue the delay between the TCP
SYN
and receiving SYN ACK packet.


Joe





__

Search, browse and book your hotels and flights
through Yahoo! Travel.
http://sg.travel.yahoo.com





  
__

Yahoo! Singapore Answers
Real people. Real questions. Real answers. Share what you know at 
http://answers.yahoo.com.sg

RE: Tools to measure TCP connection speed

[Jamie Bowden]

Ttcp will give you what you're looking for, but it's not something you
can run in the background and forget.  You have to bring it up on both
ends, and while it's running, it won't even pretend to try and be
friendly about bandwidth usage.  It'll give you a summary after it has
finished transferring whatever file(s) you feed it.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Joe Shen
Sent: Monday, March 10, 2008 11:51 AM
To: NANGO
Subject: RE: Tools to measure TCP connection speed



we do not just want to analyze e2e performance, but to
monitor network performance at IP and TCP layer.

We monitor end-to-end ping with smokeping, but as you
know, ICMP data does not reflect application layer
permance at any time. So, we set up two hosts to
measure TCP permance. 

Is there tools like smokeping to monitoring e2e TCP
connecting speed?

Joe




--- "Darden, Patrick S." <[EMAIL PROTECTED]> wrote:

> 
> 
> Best way to do it is right after the SYN just count
> "one one thousand, two one thousand" until you get
> the ACK.  This works best for RFC 1149 traffic, but
> is applicable for certain others as well.
> 
> I don't know of any automated tool, per se.  You
> really couldn't do it *well* on the software side. 
> I see a few options:
> 
> 1.  this invalidates itself, but it is easily
> doable: get one of those ethernet cards that
> includes all stack processing, and write a simple
> driver that includes a timing mechanism and a
> logger.  It invalidates itself because your
> real-life connection speeds would depend on the
> actual card you usually use, the OS, etc. ad
> nauseum, and you would be bypassing all of those.
> 
> 2.  if you are using a "free" as in open source OS,
> specifically as in Linux or FreeBSD, then you could
> write a simple kernel module that could do it.  It
> would still be wrong--but depending on your skill it
> wouldn't be too wrong.
> 
> 3.  this might actually work for you.  Check to see
> how many total TCP connections your OS can handle,
> make sure your TCP timeout is set to the default 15
> minutes, then set up a simple perl script that
> simply starts a timer, opens sockets as fast as it
> can, and when it reaches the total the OS can handle
> it lets you know the time passed.  Take that and
> divide by total number of connections and you get
> the average  It won't be very accurate, but it
> will give you some kind of idea.
> 
> Please forgive the humor
> 
> --Patrick Darden
> 
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of
> Joe Shen
> Sent: Monday, March 10, 2008 5:00 AM
> To: NANGO
> Subject: Tools to measure TCP connection speed
> 
> 
> 
> hi,
> 
>   is there any tool could measue e2e TCP connection
> speed? 
> 
> 
>   e.g. we want to measue the delay between the TCP
> SYN
> and receiving SYN ACK packet.
> 
> 
>  Joe
> 
> 
>  
>
__
> Search, browse and book your hotels and flights
> through Yahoo! Travel.
> http://sg.travel.yahoo.com
> 



  __

Yahoo! Singapore Answers 
Real people. Real questions. Real answers. Share what you know at
http://answers.yahoo.com.sg

RE: Tools to measure TCP connection speed

[Joe Shen]

we do not just want to analyze e2e performance, but to
monitor network performance at IP and TCP layer.

We monitor end-to-end ping with smokeping, but as you
know, ICMP data does not reflect application layer
permance at any time. So, we set up two hosts to
measure TCP permance. 

Is there tools like smokeping to monitoring e2e TCP
connecting speed?

Joe




--- "Darden, Patrick S." <[EMAIL PROTECTED]> wrote:

> 
> 
> Best way to do it is right after the SYN just count
> "one one thousand, two one thousand" until you get
> the ACK.  This works best for RFC 1149 traffic, but
> is applicable for certain others as well.
> 
> I don't know of any automated tool, per se.  You
> really couldn't do it *well* on the software side. 
> I see a few options:
> 
> 1.  this invalidates itself, but it is easily
> doable: get one of those ethernet cards that
> includes all stack processing, and write a simple
> driver that includes a timing mechanism and a
> logger.  It invalidates itself because your
> real-life connection speeds would depend on the
> actual card you usually use, the OS, etc. ad
> nauseum, and you would be bypassing all of those.
> 
> 2.  if you are using a "free" as in open source OS,
> specifically as in Linux or FreeBSD, then you could
> write a simple kernel module that could do it.  It
> would still be wrong--but depending on your skill it
> wouldn't be too wrong.
> 
> 3.  this might actually work for you.  Check to see
> how many total TCP connections your OS can handle,
> make sure your TCP timeout is set to the default 15
> minutes, then set up a simple perl script that
> simply starts a timer, opens sockets as fast as it
> can, and when it reaches the total the OS can handle
> it lets you know the time passed.  Take that and
> divide by total number of connections and you get
> the average  It won't be very accurate, but it
> will give you some kind of idea.
> 
> Please forgive the humor
> 
> --Patrick Darden
> 
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of
> Joe Shen
> Sent: Monday, March 10, 2008 5:00 AM
> To: NANGO
> Subject: Tools to measure TCP connection speed
> 
> 
> 
> hi,
> 
>   is there any tool could measue e2e TCP connection
> speed? 
> 
> 
>   e.g. we want to measue the delay between the TCP
> SYN
> and receiving SYN ACK packet.
> 
> 
>  Joe
> 
> 
>  
>
__
> Search, browse and book your hotels and flights
> through Yahoo! Travel.
> http://sg.travel.yahoo.com
> 



  __ 
Yahoo! Singapore Answers 
Real people. Real questions. Real answers. Share what you know at 
http://answers.yahoo.com.sg

Re: Customer-facing ACLs

[Justin Shore]

Adrian Chadd wrote:

Does anyone have any handy links to actual raw data and papers about this?

I'm sure we've all got our own personal datapoints to support automated
network probes but I'd prefer to stuff something slightly more concrete
and official(!) into the Wiki.


SANS ISC might have some useful reports.  I see a few links in this article:

http://www.incidents.org/diary.html?storyid=4045

Justin

Peering with the Internet Alert Registry

[Josh Karlin]

All,

Some of you are aware of the site for network operators:
http://iar.cs.unm.edu/  which has running for two years now.  The purpose of
the site is to detect and distribute network anomaly information to the
network operators that need to know.  The flip side of our proposed security
system, Pretty Good BGP (PGBGP), lowers the local preference of anomalous
routes on BGP routers for 24 hours, giving operators time to respond to
anomalous routes before they can fully propagate.

Now, PGBGP is in actual routing software (Quagga), which we soon hope to
distribute.  As an initial means of test, we will switch the IAR to it
(instead of scraping RIPE/RouteViews with a script). This means that we will
need peers to provide the IAR with BGP updates (we will not propagate any
route updates to your routers).  Currently we have three BGP streams, more
would be appreciated.

If you would like to contribute to our research project, please reply
directly to me.  More information about the project can be found here:
http://cs.unm.edu/~karlinjf/pgbgp/ 

Thanks!

Josh

Re: Customer-facing ACLs

[Adrian Chadd]

> >Do bots try brute force attacks on Telnet and FTP? All I see at my firewall
> >are SSH attacks and spam. But sure, if there's a lot of Telnet abuse block
> >23 too; I think it's used about as rarely by "normal" customers as SSH is.
> >
> 
> Depending on the ip space I find FTP brute force attacks 10 times more 
> common than SSH attacks. There really isn't a blanket rule you can impose.
> 
> On a different note, unless you clearly advertise that you're offering 
> filtered services I don't really find the practice ethical - and no a 
> tiny line in the TOS doesn't really cut it IMHO.
> 
> That doesn't mean it can't be done, simply spin the imposed ACL as a 
> value-add and that your customers are now on a "safer internet".

Does anyone have any handy links to actual raw data and papers about this?

I'm sure we've all got our own personal datapoints to support automated
network probes but I'd prefer to stuff something slightly more concrete
and official(!) into the Wiki.




Adrian

Re: Customer-facing ACLs

[Chris Marlatt]

Dave Pooser wrote:


Do bots try brute force attacks on Telnet and FTP? All I see at my firewall
are SSH attacks and spam. But sure, if there's a lot of Telnet abuse block
23 too; I think it's used about as rarely by "normal" customers as SSH is.



Depending on the ip space I find FTP brute force attacks 10 times more 
common than SSH attacks. There really isn't a blanket rule you can impose.


On a different note, unless you clearly advertise that you're offering 
filtered services I don't really find the practice ethical - and no a 
tiny line in the TOS doesn't really cut it IMHO.


That doesn't mean it can't be done, simply spin the imposed ACL as a 
value-add and that your customers are now on a "safer internet".


Regards,

Chris

Re: Tools to measure TCP connection speed

[Christopher Morrow]

On Mon, Mar 10, 2008 at 4:00 AM, Joe Shen <[EMAIL PROTECTED]> wrote:
>
>  hi,
>
>   is there any tool could measue e2e TCP connection
>  speed?
>
>
>   e.g. we want to measue the delay between the TCP SYN
>  and receiving SYN ACK packet.

So, all you want to know is basic RTT? Do you want to know about the
network? or the hosts? or the whole 'system' ?

One simple thing might be to just use WireShark which can calculate
the various timings on an individual tcp-session basis. Another poster
suggests tcpdump, also a fine solution...

-Chris

RE: Tools to measure TCP connection speed

[Michienne Dixon]

We use LAN Traffic v2 to test speeds on our network. 
http://www.omnicor.com/netest.htm

-
Michienne Dixon
Network Administrator
liNKCity
312 Armour Rd
North Kansas City, MO  64116
www.linkcity.org
(816) 412-7990



From: Joe Shen
Sent: Mon 3/10/2008 4:00 AM
To: NANGO
Subject: Tools to measure TCP connection speed


hi,

  is there any tool could measue e2e TCP connection
speed? 


  e.g. we want to measue the delay between the TCP SYN
and receiving SYN ACK packet.


 Joe


  __
Search, browse and book your hotels and flights through Yahoo! Travel.
http://sg.travel.yahoo.com

RE: Tools to measure TCP connection speed

[Ray Burkholder]

> 
> On 2008-03-10, Joe Shen <[EMAIL PROTECTED]> wrote:
> >   is there any tool could measue e2e TCP connection speed?
> 

WireShark, which also has a basic analysis package built-in for error and
connection setup statistics.


-- 
Scanned for viruses and dangerous content at 
http://www.oneunified.net and is believed to be clean.

Re: Tools to measure TCP connection speed

[Stuart Henderson]

On 2008-03-10, Joe Shen <[EMAIL PROTECTED]> wrote:
>   is there any tool could measue e2e TCP connection
> speed? 

hping (or tcpdump while you make a connection by any method).

RE: Tools to measure TCP connection speed

[Darden, Patrick S.]

Best way to do it is right after the SYN just count "one one thousand, two one 
thousand" until you get the ACK.  This works best for RFC 1149 traffic, but is 
applicable for certain others as well.

I don't know of any automated tool, per se.  You really couldn't do it *well* 
on the software side.  I see a few options:

1.  this invalidates itself, but it is easily doable: get one of those ethernet 
cards that includes all stack processing, and write a simple driver that 
includes a timing mechanism and a logger.  It invalidates itself because your 
real-life connection speeds would depend on the actual card you usually use, 
the OS, etc. ad nauseum, and you would be bypassing all of those.

2.  if you are using a "free" as in open source OS, specifically as in Linux or 
FreeBSD, then you could write a simple kernel module that could do it.  It 
would still be wrong--but depending on your skill it wouldn't be too wrong.

3.  this might actually work for you.  Check to see how many total TCP 
connections your OS can handle, make sure your TCP timeout is set to the 
default 15 minutes, then set up a simple perl script that simply starts a 
timer, opens sockets as fast as it can, and when it reaches the total the OS 
can handle it lets you know the time passed.  Take that and divide by total 
number of connections and you get the average  It won't be very accurate, 
but it will give you some kind of idea.

Please forgive the humor

--Patrick Darden



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
Joe Shen
Sent: Monday, March 10, 2008 5:00 AM
To: NANGO
Subject: Tools to measure TCP connection speed



hi,

  is there any tool could measue e2e TCP connection
speed? 


  e.g. we want to measue the delay between the TCP SYN
and receiving SYN ACK packet.


 Joe


  __
Search, browse and book your hotels and flights through Yahoo! Travel.
http://sg.travel.yahoo.com

Tools to measure TCP connection speed

[Joe Shen]

hi,

  is there any tool could measue e2e TCP connection
speed? 


  e.g. we want to measue the delay between the TCP SYN
and receiving SYN ACK packet.


 Joe


  __
Search, browse and book your hotels and flights through Yahoo! Travel.
http://sg.travel.yahoo.com

Re: NANOG laptops (was Re: Customer-facing ACLs)

[Mark Prior]

William Allen Simpson wrote:


Marshall Eubanks wrote:
I used to count the proportion of Mac laptops in the room (or, at 
least, my row) to pass the time when I was bored.


 I remember at the 1999 Washington IETF I saw exactly one, and I
could hear people whisper about it around me.


I used to attend with various Powerbook flavors over the years.  I'm sure
that I wasn't the only person with a Mac at IETF in 1999.  I snuck my SO
into the terminal room with her Mac, too


So there was two of us at least :) I probably still had my "Blackbird".

Mark.