Re: ISP phishing

[Valdis . Kletnieks]

On Fri, 24 Jun 2005 01:20:27 +0200, Gadi Evron said:

> Thing is, user-trust or no user-trust, they click by the masses.

One wonders how many people would click on a phish from the First
National Bank of Dancing Hamsters, just because


pgpa4XUbqVkbA.pgp
Description: PGP signature

Re: ISP phishing

[Joel Jaeggli]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 24 Jun 2005, Gadi Evron wrote:


Joel Jaeggli wrote:




The bigger issue is that users simply don't trust any kind of "official
communication" anymore and I don't see anything other than pki that
could actually restore that.


PKI alone won't solve it, but we are not trying to "fix" phishing here
(good thought though!). I agree.

Thing is, user-trust or no user-trust, they click by the masses.


I agree, to elaborate:

For us, I see an increasing number of situations where our customers are 
begining to discard messages we send them about their account because the 
information we're imparting is hard to distinguish from all the other crap 
that we don't manage to filter.


Claude Shannon could be invoked here. What we have is a noisy 
communication channel. The phishers are counting on that because the end 
users are trying to filter all this crap, and the false postive rate of 
humans trying to distinguish signal from noise is non zero, so eventually 
people identify the noise as signal. When the noise level gets high enough 
the signal doesn't get through. There are two solutions really, increase 
the volume of signal that you send, (basically send more messages) in 
hopes that get through, apply forward error correction (something that 
gives the messages a higher likelyhood of being interpreted as signal. If 
the phishers can replicated the FEC method then the channel gets noisy 
again.


 >   Gadi.




- -- 
- --

Joel Jaeggli   Unix Consulting [EMAIL PROTECTED]
GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: pgpenvelope 2.10.2 - http://pgpenvelope.sourceforge.net/

iD8DBQFCu0118AA1q7Z/VrIRAnGQAJ4rNpG1C+kzSDRwlrJEC+EBWemRmQCfUSjv
o467gHoKGCm0JGh0VTvbBE4=
=Rq+N
-END PGP SIGNATURE-

Re: ISP phishing

[Gadi Evron]

Joel Jaeggli wrote:



> The bigger issue is that users simply don't trust any kind of "official
> communication" anymore and I don't see anything other than pki that
> could actually restore that.

PKI alone won't solve it, but we are not trying to "fix" phishing here
(good thought though!). I agree.

Thing is, user-trust or no user-trust, they click by the masses.

Gadi.

Re: ISP phishing

[Joel Jaeggli]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 23 Jun 2005, Gadi Evron wrote:


Due to the huge number of variants in the wild, our AV software can't
keep up (probably nobody's can). Instead, we enabled a global rule which
blocks any email from accounts such as billing, root, postmaster,
antivirus, abuse, security, etc. which don't originate from our
management IP space where our people work. As a result, we have stopped
these phishing scams for our users dead in their tracks.

-Robert


We did as well, but we did not yet find a solution for legit bounces..
it naturally breaks that.

It's a temporary solution to what I see that is going to become very big.


The bigger issue is that users simply don't trust any kind of "official 
communication" anymore and I don't see anything other than pki that could 
actually restore that.



- -- 
- --

Joel Jaeggli   Unix Consulting [EMAIL PROTECTED]
GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: pgpenvelope 2.10.2 - http://pgpenvelope.sourceforge.net/

iD8DBQFCuzh+8AA1q7Z/VrIRAoLNAJwIlI+xeEk5TDu22mhGMYVfFIypGACfb2BR
/hUazqmv3nleXPriXwuMeSY=
=erGj
-END PGP SIGNATURE-

Engineer headcount calculations

[Luke Parrish]

Measuring a customer service rep's time on a daily basis is a pretty easy 
and straightforward task. You can get down to the minute by minute level of 
how a CSR spends their time each day. You can also easily relate that back 
to customer growth which gives you how many CSR's you need for your next 
budget year. CSR's have a set of tasks to complete that rarely change day 
to day.


However, what about a network engineer?

A day in the life of an engineer:

outage resolution
proactive projects(some 2 hours and some 300 hours)
reactive projects(some 2 hours and some 300 hours)
customer escalation
escalated network issue
maintenance windows
writing/researching change management
time spent in lab researching network issues
turning up new service
planning for new service
turning down old service
taking phone calls from internal business units needing support
configuring interfaces for new dedicated customers
ip administration(sometimes 3 minutes per request sometimes 2 days of 
justification on a request)

equipment upgrades
TAC research
equipment evaluation
reports
shipping equipment
boxing equipment
meetings

etc etc etc etc etc etc, everyone knows where I am going.

So the million dollar question, how do you account for their time to prove 
in a business case that you need to add additional headcount. If you plan 
on adding 110,000 DSL subs next year then we all know that we have to add 
engineers to support the network that will have to be built. However, how 
do you prove that with numbers?


I can say, I have to turn up 250 new DSLAMs, 60 new routers, 18 new 
internet drains, etc etc which I can easily relate back to manhours for 
turnup. However how do you allocate manhours to maintenance of the network? 
There are some easy ones, 1 IOS upgrade a year times number of devices on 
the network, 1 bandwidth upgrade per year times number of CO's, etc etc. 
But what about the day to day that I listed above?


We have to sell this idea to accountants, not other engineers, they only 
see numbers on paper. Its easy to all of us, we know how many people we 
need, but how do you put a business case together to sell it?


Can anyone out there share what type of system they use to account for 
engineers time, or really any insight at all would be helpful.


One answer would be a system that the engineer would open and close time 
based tickets everytime they made a move during the day. However I dont 
know many network engineers at the enable level that are restricted this 
way, however it is an option.


luke

Re: Localized mail servers, global scope

[Joe Abley]

On 2005-06-23, at 10:57, Suresh Ramasubramanian wrote:


Wild idea and there's just too much good german beer here at MAAWG
(www.maawg.org) in Dusseldorf, but .. anybody tried anycasting a
mailserver?

Operationally that is ...


I know of people who have anycasted the address used by their clients  
for mail submission using SMTP (so that clients connect to a stable  
address, and the node which services their request varies according  
to where they are connecting from).


Like all applications of service distribution using anycast, care is  
required: e.g. a stable, internal network with a well-known topology,  
and anycast nodes placed such that node selection by clients is  
consistent, packet-to-packet, for periods of time far exceeding the  
expected maximum transaction time.


The places I have seen this done have had POPs connected with  
expensive and congested links, so keeping mail submission from  
customers local and snappy was a big win.


I think you're talking about anycasting a server across the Internet  
to act as a low-numbered MX, though. I haven't met anybody who  
thought that was a good idea, yet. :-)



Joe

Re: md5 for bgp tcp sessions

[Richard A Steenbergen]

On Thu, Jun 23, 2005 at 05:57:05AM -0400, Todd Underwood wrote:
> 
> my understanding is that md5 is still checked before the ttl-hack
> check takes place on cisco (and perhaps most router platforms).  new
> attack vector for less security than you had before.  oh well.  ras:
> can you confirm that it is possible to implement ttl-hack and have it
> check *before* md5 signature checks?

The TTL hack itself (this is the one where your neighbor sets their 
outbound TTL to 255 and then you can drop the packet if it has a TTL less 
than 254, in case anyone wasn't paying attention) can be implemented on 
the data plane in the receive/loopback hardware based filters before any 
TCP processing happens or the packet ever gets near the management cpu, 
since it is an IP-specific check. The only thing that the TTL hack 
guarantees is that the packet hasn't traveled over any routed network to 
get to you, so for example you could still get hit by directly connected 
networks (across a public exchange with malicious or compromised 
participants, for example). This is different from the issue of whether 
the sequence number is checked before the MD5 signature.

Remember the entire point of this attack was that some bright person 
"realized" that with most people having a default TCP window size of 16384 
(btw I'm told that this isn't necessarily the case, and that at least some 
vendors are lowering their socket buffers on the BGP specific sockets for 
other unrelated reasons) or 2^14 you only need to try 2^18 combinations 
per ephemeral port and bgp port pair instead of 2^32, times the number of 
ephemeral ports you must test, times 2 to handle BGP collision detection 
which may set the session up in either direction. You still have to throw 
a couple billion packets at the victim and hope for a match, and only 
after you get this match do you need to proceed to the next step of 
validation on the one packet that managed to get through. If you are doing 
MD5 validation on every packet that comes in before you check the other 
criteria like sequence number, you are opening yourself up to a very easy 
DoS by anyone who wants to throw junk MD5 signed packets at you.

> the chaos (and crappy quality of the implementations) during the panic
> demonstrates two other things:  rolling out magic code because your
> vendor tells you to is a bad idea;  slapping together a hack on top of 
> a well-designed protocol without careful thought and testing is a
> terrible idea.  

This wasn't the first or last time the vendors have told us we must 
upgrade immediately to some buggy new code because of some secret reason 
they can't disclose without killing us afterwards, only to find out it was 
a dud issue we wouldn't have cared about if we had been given technical 
details beforehand. While I suppose this is slightly better than them 
putting out a press release 24 hours after the discovery with everything 
but some example exploit code that compiles on linux, I think the point 
that we're all trying to make is that we'd like the vendors to find the 
happy middle ground between stupidity and paranoia.

-- 
Richard A Steenbergen <[EMAIL PROTECTED]>   http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

Re: Localized mail servers, global scope

[Brad Knowles]

At 12:04 PM -0400 2005-06-23, Derek Diget wrote:


 I replied privately to the original poster since I was not on NANOG-post,
 but this would be interesting if the anycasting was tied into some load
 balancers doing geographical balancing.


	GSLB only works if each and every server can supply information 
appropriate to whatever question might be asked, based solely on 
where the incoming connection is being generated.


	In the case of e-mail, at this point you know nothing about the 
recipient.  Unfortunately, the OP has recipients distributed around 
at least 25 sites in the world, and that's where he really needs his 
load-balancing.  Anycasting and GSLB isn't going to help this problem.



 But certain vendors do have MTAs that can kind of do this.  I am
 thinking about Sun's Messaging Server.  Chapter 12 of their Deployment
 Planning Guide 
 mentions a "Distributed Topology" that I thinks fits the original
 posters requirement pretty closely.


	Newsflash: MTAs can be used as both SMTP/SMTP routers and 
SMTP/local delivery gateways!


	Riiight.  I don't suppose anyone here saw my previous 
mention of the Lachman-LASER IETF draft for doing mail routing via 
LDAP?  Heck, what about mail routing via something like NIS?  Or do 
you want me to go back into ancient history and dig up UUCP and the 
route mapping tables that were developed?



  You can abstract the mail reception
 (SMTP/MSA) routing behind the MTAs and also abstract the mail retrieval
 (IMAP/POP/Webmail) behind the Messaging MultiPlexors (MMPs).  I would
 think if further discussion on this vendors product is wanted, then
 please see a web site  that has information on the user
 mailing list.


	Setting up a router-only external infrastructure which then 
passes on incoming messages to the appropriate back-end is nothing 
new.  See  and 
.


	Trying to dress up something basic like this and then turn around 
and sell it as a commercial service is also not new.


--
Brad Knowles, <[EMAIL PROTECTED]>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755

  SAGE member since 1995.  See  for more info.

Re: Localized mail servers, global scope

[Derek Diget]

Stepping out of the lurker's doorway for the first time.


On Jun 23, 2005 at 20:27 +0530, Suresh Ramasubramanian wrote:
=>Wild idea and there's just too much good german beer here at MAAWG
=>(www.maawg.org) in Dusseldorf, but .. anybody tried anycasting a
=>mailserver?
=>
=>Operationally that is ...

I replied privately to the original poster since I was not on NANOG-post, 
but this would be interesting if the anycasting was tied into some load 
balancers doing geographical balancing.  That is all I dare say because 
I am already beyond my realm of comfort. :)  (I am a Solaris/Linux sys 
admin/mail admin/whatever-else-gets-thrown-at-me worker bee. :)


=>On 23/06/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
=>> 
=>> > You don't need a central MX if each site MTA knows which users are at
=>> > which sites. Incoming email may have to take an extra hop if it comes in
=>> > to the wrong site, but that's a consequence of the specification that no
=>> > implementation can fix.
=>> 
=>> In other words, SMTP does not have the equivalent of an
=>> HTTP redirect which is what he wants here. Maybe SMTP
=>> really is broken? ;-)

But certain vendors do have MTAs that can kind of do this.  I am 
thinking about Sun's Messaging Server.  Chapter 12 of their Deployment 
Planning Guide  
mentions a "Distributed Topology" that I thinks fits the original 
posters requirement pretty closely.  You can abstract the mail reception 
(SMTP/MSA) routing behind the MTAs and also abstract the mail retrieval 
(IMAP/POP/Webmail) behind the Messaging MultiPlexors (MMPs).  I would 
think if further discussion on this vendors product is wanted, then 
please see a web site  that has information on the user 
mailing list.


Stepping back into the lurker's door way as the sun is to bright. :)


--
***
Derek DigetOffice of Information Technology
Western Michigan University - Kalamazoo  Michigan  USA - www.wmich.edu/
***

Re: md5 for bgp tcp sessions

[Robert E . Seastrom]

Eric Gauthier <[EMAIL PROTECTED]> writes:

> Honestly, I completely agree with you that MD5'ing our OSPF
> adjacencies isn't a great idea (I've so far stalled its roll-out).
> I strongly argued against it internally.  There were, however, those
> in both the networking and security groups that were concerned about
> the OSPF vulnerabilities that were pointed out recently and were in
> favor of the MD5s as the mitigation method.

passive-interface is your friend.

---rob 

Re: md5 for bgp tcp sessions

[Jared Mauch]

On Thu, Jun 23, 2005 at 05:57:05AM -0400, Todd Underwood wrote:
> 
> ras, all,
> 
> On Thu, Jun 23, 2005 at 12:14:12AM -0400, Richard A Steenbergen wrote:
> > On Wed, Jun 22, 2005 at 10:04:09PM -0400, Todd Underwood wrote:
> 
> > >   a) many (all?) implementations of md5 protection of tcp expose
> > > new, easy-to-exploit vulnerabilities in host OSes.  md5 verification
> > > is slow and done on a main processor of most routers.  md5
> > > verification typically takes places *before* the sequence number,
> > > ports, and ip are checked to see whether they apply to a valid
> > > session.  as a result, you've exposed a trivial processor DOS to your
> > > box.  
> > 
> > Well, I think they've finally fixed this one by now, at least everyone 
> > that I'm aware of has done so. Immediately following the whining to start 
> > deploying MD5 is was certainly the case that many implementations did 
> > stupid stuff like process MD5 before running other validity checks like 
> > sequence numbers which are far less computationally intensive, and there 
> > were a few MSS bugs that popped up, but they should have all been worked 
> > out by now. I don't think that anyone running modern code is suffering any 
> > more attack potential because of this.
> 
> my understanding is that md5 is still checked before the ttl-hack
> check takes place on cisco (and perhaps most router platforms).  new
> attack vector for less security than you had before.  oh well.  ras:
> can you confirm that it is possible to implement ttl-hack and have it
> check *before* md5 signature checks?

Last I knew there was still a bug open on this that has gotten
little/no action for at least half a year on this issue, I would
think that in 6mos someone at Cisco could take the time to research
the bug and fix it.  (I'll leave out the part about releasing TAC supported
code with a fix).

I believe the bugid is CSCee73956

- Jared

-- 
Jared Mauch  | pgp key available via finger from [EMAIL PROTECTED]
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

Re: md5 for bgp tcp sessions

[Jared Mauch]

On Thu, Jun 23, 2005 at 10:27:49AM -0400, Todd Underwood wrote:
> 
> marty,
> 
> On Thu, Jun 23, 2005 at 10:22:07AM -0400, Hannigan, Martin wrote:
> > > rolling out magic code because your
> > > vendor tells you to is a bad idea;  
> > 
> > That's mostly the result of the calamitous failure in vulnerability 
> > release methodology, not Operator stupidity. 
> 
> totally agreed.  vendors c, j and several others should be *ashamed*
> of the way that they handled and continue to handle this issue: they

Hmm, Do you mean NISCC?  I think they were
driving the issue:

http://www.uniras.gov.uk/niscc/docs/al-20040420-00199.html?lang=en

> have yet to admit that they raised a panic (in secret, with no facts,
> so that they could not be refuted) over a basic fact of the way tcp
> works, creating outages and instability to fix a non-problem.
> 
> operators in those circumstances had little choice but to roll out
> "critical security fixes", but i think we all deserve an apology, an
> explanation and a commitment to do better in the future.

Come on folks, this was over a year ago, we've all grown
some (well, at least older) and hopefully wiser in how to handle
these situations as they come up.

I suspect the vendors, NISCC/UNIRAS, and various global CERTs
have been learning from these events, but it was awhile ago so take
the lesson and move on.

- Jared

-- 
Jared Mauch  | pgp key available via finger from [EMAIL PROTECTED]
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

Re: Localized mail servers, global scope

[Suresh Ramasubramanian]

Wild idea and there's just too much good german beer here at MAAWG
(www.maawg.org) in Dusseldorf, but .. anybody tried anycasting a
mailserver?

Operationally that is ...

On 23/06/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 
> > You don't need a central MX if each site MTA knows which users are at
> > which sites. Incoming email may have to take an extra hop if it comes in
> > to the wrong site, but that's a consequence of the specification that no
> > implementation can fix.
> 
> In other words, SMTP does not have the equivalent of an
> HTTP redirect which is what he wants here. Maybe SMTP
> really is broken? ;-)
> 
> --Michael Dillon
> 


-- 
Suresh Ramasubramanian ([EMAIL PROTECTED])

Re: md5 for bgp tcp sessions

[Joe Abley]

On 2005-06-23, at 09:57, Eric Gauthier wrote:

likely need to make modifications to our IGP/EGP setup.  Though  
we filter

OSPF multicast traffic, we wanted to add in MD5 passwords to our
neighbors.


just a quick comment here.  i would encourage you not to do that.


Honestly, I completely agree with you that MD5'ing our OSPF  
adjacencies isn't

a great idea (I've so far stalled its roll-out).


Just in case it's not obvious to any onlookers here, Eric was talking  
about using MD5 authentication in OSPF adjacencies, and Todd is  
talking about using the TCP MD5 signature option (RFC2385) between  
BGP peers.


They are two different things (although they both involve routing  
protocols and the MD5 algorithm): not all arguments for or against  
one will apply to the other.



Joe

Level3

[Robert Mathews]

Good morning..

Have any noted significant performance issues (routing loops etc.) in
interconnects with Level3 infrastructure - particularly in Chicago, New
York or Seattle within the last 4 days?

Any feedback offline would be great.

Thank you.

Re: ISP phishing

[Gadi Evron]

Robert Boyle wrote:
> 
> At 05:37 AM 6/23/2005, you wrote:
> 
>> Hi guys. I notice a large increase in recent weeks of ISP directed
>> phishing - largely because of worms moving backward to using the user's
>> own domain for the spam, but not just in the from: address.
>>
>> I believe this started out as a "let's feel this out" or "wow, that
>> worked, let's phish ISP's directly too". I now have several reports
>> that point to this becoming a serious problem.
>>
>> Old with a spark of new, but definitely a problem.
>>
>> Anyone else dealing with this?
> 
> 
> Due to the huge number of variants in the wild, our AV software can't
> keep up (probably nobody's can). Instead, we enabled a global rule which
> blocks any email from accounts such as billing, root, postmaster,
> antivirus, abuse, security, etc. which don't originate from our
> management IP space where our people work. As a result, we have stopped
> these phishing scams for our users dead in their tracks.
> 
> -Robert

We did as well, but we did not yet find a solution for legit bounces..
it naturally breaks that.

It's a temporary solution to what I see that is going to become very big.

Re: md5 for bgp tcp sessions

[Todd Underwood]

marty,

On Thu, Jun 23, 2005 at 10:22:07AM -0400, Hannigan, Martin wrote:
> > rolling out magic code because your
> > vendor tells you to is a bad idea;  
> 
> That's mostly the result of the calamitous failure in vulnerability 
> release methodology, not Operator stupidity. 

totally agreed.  vendors c, j and several others should be *ashamed*
of the way that they handled and continue to handle this issue: they
have yet to admit that they raised a panic (in secret, with no facts,
so that they could not be refuted) over a basic fact of the way tcp
works, creating outages and instability to fix a non-problem.

operators in those circumstances had little choice but to roll out
"critical security fixes", but i think we all deserve an apology, an
explanation and a commitment to do better in the future.

t

-- 
_
todd underwood
director of operations & security
renesys - interdomain intelligence
[EMAIL PROTECTED]   www.renesys.com

RE: md5 for bgp tcp sessions

[Hannigan, Martin]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
> Todd Underwood
> Sent: Thursday, June 23, 2005 5:57 AM
> To: Richard A Steenbergen
> Cc: nanog@merit.edu
> Subject: Re: md5 for bgp tcp sessions
> 
> 
> 
> ras, all,
> 
> On Thu, Jun 23, 2005 at 12:14:12AM -0400, Richard A Steenbergen wrote:
> > On Wed, Jun 22, 2005 at 10:04:09PM -0400, Todd Underwood wrote:
> 
> rolling out magic code because your
> vendor tells you to is a bad idea;  

That's mostly the result of the calamitous failure in vulnerability 
release methodology, not Operator stupidity. 

-M<

Re: Localized mail servers, global scope

[Dave Stewart]

how many different bandaids are applied. It is time
to re-engineer with the benefit of hindsight.


However desirable this may be, don't you agree that no matter what 
mechanism comes along, there's a huge inertia to overcome.


We can debate the correct way to handle email forever.  But of greater 
interest would be how you're going to get everyone to go along and change.

RE: md5 for bgp tcp sessions

[Barry Greene (bgreene)]

 

> my understanding is that md5 is still checked before the 
> ttl-hack check takes place on cisco (and perhaps most router 
> platforms).  new attack vector for less security than you had 
> before.  oh well.  ras:
> can you confirm that it is possible to implement ttl-hack and 
> have it check *before* md5 signature checks?

You do not have a correct understanding of how GPTM is suppose to work.
If you can, you need to do this check as close to the punt out of the
data plane as possible. Optimally in the ASIC (if the ASIC can be coded
to do a TTL check). On Cisco gear we're coding from inside out - doing
GPTM in the routing code (BGP) - then in the receive path wrapper (rACL
and CoPP) - then in the ASIC raw queue (if it can) - then in the ASIC's
receive path primitives. The GPTM was all about dropping the packet
before they got near the route process. 

If you want more details, let me know and I'll send them privately.
 

Re: Localized mail servers, global scope

[Tony Finch]

On Thu, 23 Jun 2005 [EMAIL PROTECTED] wrote:
>
> Perhaps this is the time to find a new general solution rather than
> continuing to tack extensions on the existing email service?

None of the email replacement proposals I have seen are likely to get any
significant deployment because none of them is sufficiently better than
SMTP. Without a compelling incentive it won't happen because network
effects strongly favour staying with what the majority of people use.

> I don't have the answers but I think the 10 years of failure to put a
> dent in spam have shown beyond the shadow of a doubt that Internet email
> is broken by design and bandaids are not going to fix this, no matter
> how many different bandaids are applied.

One of the most important features of email is that it allows you to
receive messages from people you have not previously communicated with.
That, combined with the fact that email is cheap, makes spam inevitable
whatever technical infrastructure you use. It is not a failure of SMTP.

Another way to see that spam is not caused by weaknesses in SMTP is by
observing that it occurs in other protocols: usenet spam, blog spam, wiki
spam, spim, etc. Wherever there is an audience there will be spam.

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

Re: md5 for bgp tcp sessions

[Eric Gauthier]

Todd,

> eric, all, not to pick on eric at all, but since he raised the issue...

I always assume and, frankly hope, that when I post something someone will
pipe up and point out anything thats inaccurate, needs clarification,
is a bad idea, etc.

> > likely need to make modifications to our IGP/EGP setup.  Though we filter 
> > OSPF multicast traffic, we wanted to add in MD5 passwords to our
> > neighbors.
> 
> just a quick comment here.  i would encourage you not to do that.  

Honestly, I completely agree with you that MD5'ing our OSPF adjacencies isn't
a great idea (I've so far stalled its roll-out).  I strongly argued against it 
internally.  There were, however, those in both the networking and security 
groups that were concerned about the OSPF vulnerabilities that were pointed 
out recently and were in favor of the MD5s as the mitigation method.  I used 
the discussion as a point in favor of moving to IS-IS because, since we don't
route CLNS on our campus, IS-IS would be more immune to that form of attack.  
I just noted the issue in my response because it was one of the reaons why
we're deciding to move from OSPF to IS-IS, rather than as a recommendation.

Thanks for pointing it out!

Eric :)

Re: ISP phishing

[Robert Boyle]

At 05:37 AM 6/23/2005, you wrote:

Hi guys. I notice a large increase in recent weeks of ISP directed
phishing - largely because of worms moving backward to using the user's
own domain for the spam, but not just in the from: address.

I believe this started out as a "let's feel this out" or "wow, that
worked, let's phish ISP's directly too". I now have several reports that 
point to this becoming a serious problem.


Old with a spark of new, but definitely a problem.

Anyone else dealing with this?


Due to the huge number of variants in the wild, our AV software can't keep 
up (probably nobody's can). Instead, we enabled a global rule which blocks 
any email from accounts such as billing, root, postmaster, antivirus, 
abuse, security, etc. which don't originate from our management IP space 
where our people work. As a result, we have stopped these phishing scams 
for our users dead in their tracks.


-Robert


Tellurian Networks - The Ultimate Internet Connection
http://www.tellurian.com | 888-TELLURIAN | 973-300-9211
"Well done is better than well said." - Benjamin Franklin

Re: Localized mail servers, global scope

[Dave Crocker]

I don't have the answers but I think the 10 years of
failure to put a dent in spam have shown beyond the
shadow of a doubt that Internet email is broken by
design and bandaids are not going to fix this, no matter
how many different bandaids are applied. It is time
to re-engineer with the benefit of hindsight.


ready, fire, aim.

we aren't hitting the target.  the gun must be broken.

couldn't be that we have lousy eyesight.  or that the ground is shaking.


folks...

when we look at email as a complex human communication service, and we explain 
spam as an intrusion into the model of using that service constructively, and 
we can formulate reasonable models of "repair" that do not break the broad 
utility of service, and we find that we cannot engineer changes to the 
existing service  to implement these human-level "repairs", THEN it will be 
time to consider "re-engineering" email.
begin:vcard
fn:Dave Crocker
n:Crocker;Dave
email;internet:dcrocker a t ...
tel;work:+1.408.246.8253
url:http://bbiw.net
version:2.1
end:vcard

Re: E-Mail authentication fight looming: Microsoft pushing Sender ID

[Rich Kulawiec]

On Wed, Jun 22, 2005 at 06:39:07PM -0700, william(at)elan.net wrote:
> P.S. It would really be great if IETF remained true to its origin
> and goals did did technical reviews and selected proposals based on
> the technical capabilities and not on what large company is exerting 
> pressure on them (especially not by means of press announcements).

Yes, it would.  It would also be great if the IETF realized that there is
really very little need for email authentication: (a) forgery is a minor
problem compared to spam, and even solving the forgery problem completely
(which isn't gonna happen) would have a temporary and negligible effect on
spam; (b) the authentication problem can't be "solved" anyway until the
complete lack of security on hundreds of millions of network endpoints
is "solved"; and (c) the originating IP address of any SMTP connection
tells you _exactly_ who is responsible for that traffic, whatever it
turns out to be.

---Rsk

Re: Localized mail servers, global scope

[Michael . Dillon]

> In the case where XREDIRECT cannot be negotiated, the server will just
> have to accept and forward the message itself.
> 
> There's obviously a lot of work involved in deciding the exact
> mechanism. Is gb.example.net looked up via MX, SRV, or something else?
> Can clients cache the name, and for how long, or do they need to
> initiate a new SMTP connection to the MXer for each new message, just
> to be told to redirect? Would extending the MX lookup mechanism with
> SRV records to direct to the correct server in the first place help?
> What about the spam implications?

All good questions that probably need to be discussed on
some email services mailing list rather than NANOG. But
don't be shy, go all the way. We are really saying that
the UUCP style relaying inherent in the current SMTP mail
system is not necessarily a good thing and mail server
operators should not be forced into relaying. But when
you follow this through to giving mail server operators
the ability to redirect SMTP connections, then you are
really saying, "Let's seperate email routing from 
email delivery". Perhaps this is the time to find a new
general solution rather than continuing to tack extensions
on the existing email service?

I don't have the answers but I think the 10 years of
failure to put a dent in spam have shown beyond the
shadow of a doubt that Internet email is broken by
design and bandaids are not going to fix this, no matter
how many different bandaids are applied. It is time
to re-engineer with the benefit of hindsight.

--Michael Dillon

Re: Localized mail servers, global scope

[Dave Crocker]

> Many mail servers don't know
a user's forwarding address at SMTP time; 


ahh, right.

something about email being s/f, and therefore not direct.

requiring 'the next hop' to have complete knowledge doesn't work.  requiring a 
particular hop to the 'the last hop' also causes problems.


hmm.  i wonder if there is a lesson, here, for path registration schemes like 
spf and sender-id?


tnx.

d/
begin:vcard
fn:Dave Crocker
n:Crocker;Dave
email;internet:dcrocker a t ...
tel;work:+1.408.246.8253
url:http://bbiw.net
version:2.1
end:vcard

Re: Localized mail servers, global scope

[william(at)elan.net]

On Thu, 23 Jun 2005 [EMAIL PROTECTED] wrote:


You don't need a central MX if each site MTA knows which users are at
which sites. Incoming email may have to take an extra hop if it comes in
to the wrong site, but that's a consequence of the specification that no
implementation can fix.


In other words, SMTP does not have the equivalent of an
HTTP redirect which is what he wants here. Maybe SMTP
really is broken? ;-)


HTTP is 100% client-server protocol so redirect is server telling client 
to go somewhere else (which is exactly what HTTP redirect does).


But SMTP is store-forward system like ip itself. In store-forward 
redirection is changing of connection path by intermediate system.

So with ip this is handled by routers and transparent proxy servers.
In SMTP this is handled by forwarding systems which change mail
transmission connection and redirect and pass message somewhere else.

So we do have redirect functionality SMTP, its just not done same
way as HTTP because of differences in system infrastructure.

P.S. Somewhat related work of mine:
 
http://www.elan.net/~william/emailsecurity/draft-leibzon-emailredirection-traceheaders-01.html

--
William Leibzon
Elan Networks
[EMAIL PROTECTED]

openning party on 06/25/2005 11pm Coordinated Universal Time

[codewarrior]

morning all , experts

i am proud to announce a european cuseeme test reflector
cuseeme was a free available peer 2 peer multiconferencing
videoconferencing application for mac and pc

more info about installation and history:
http://www.cuseeme.de/

its open now

cuseeme.dyndns.tv CID 0 64/150

regards
the

the cu-team
***
join its free http://www.isabel.de/
and support free cuseeme

Re: Localized mail servers, global scope

[Tony Finch]

On Thu, 23 Jun 2005, Dave Crocker wrote:
>
> i seem to recall a similar redirect mechanism in SMTP some time ago.  not
> worth the effort; broken; or somesuch.

The 251 and 551 forwarding address responses. Many mail servers don't know
a user's forwarding address at SMTP time; most mail servers treat any 5xx
response to RCPT TO the same way; mail servers don't want to maintain a
local database of forwarding addresses culled from 251 responses...

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

Re: Localized mail servers, global scope

[Dave Crocker]

In his case, it sounds like he actually has a business case
for solution 3 above. 


I think there is *always* a business case for making infrastructure 
communications services work efficiently and reliably.


However the world is pretty consistent about efforts to fix long-standing 
human problems, such as failure to run a service adequately.  How often does a 
long-standing problematic operation get fixed?


Change is certainly possible.

It just isn't probable.

d/
begin:vcard
fn:Dave Crocker
n:Crocker;Dave
email;internet:dcrocker a t ...
tel;work:+1.408.246.8253
url:http://bbiw.net
version:2.1
end:vcard

Re: Localized mail servers, global scope

[Dave Crocker]

In other words, SMTP does not have the equivalent of an
HTTP redirect which is what he wants here. Maybe SMTP
really is broken? ;-)


hmm.

i seem to recall a similar redirect mechanism in SMTP some time ago.  not 
worth the effort; broken; or somesuch.


anyhow, once you've hit a server, the benefit of having it issue a redirect is 
much smaller than finding a way to avoid hitting it in the first place.


d/
begin:vcard
fn:Dave Crocker
n:Crocker;Dave
email;internet:dcrocker a t ...
tel;work:+1.408.246.8253
url:http://bbiw.net
version:2.1
end:vcard

Re: E-Mail authentication fight looming: Microsoft pushing Sender ID

[Dave Crocker]

Not wanting to throw gasoline on an already raging e-mail
authentication fire, but it _does_ look like a fight is
gearing up between Domainkeys Identified Mail (DKIM), 



The real fight is to find ANY techniques that have long-term, global benefit 
in reducing spam.


Yes, advocates for particular techniques are getting aggressive when they have 
any leverage, but the market tends to be good at marginalizing schemes that do 
not really provide benefit.


It's a big network out there.
begin:vcard
fn:Dave Crocker
n:Crocker;Dave
email;internet:dcrocker a t ...
tel;work:+1.408.246.8253
url:http://bbiw.net
version:2.1
end:vcard

Re: OSPF -vs- ISIS

[Dan Evans]

Thanks to everyone who offered advice and links to resources. The
information I've gathered with your help will greatly assist me moving
forward, regardless of our decision on which protocol to use.

Regards,

Daniel

Re: Localized mail servers, global scope

[Peter Corlett]

<[EMAIL PROTECTED]> wrote:
[...]
> In other words, SMTP does not have the equivalent of an HTTP
> redirect which is what he wants here. Maybe SMTP really is broken?
> ;-)

If you don't mind dirty, unreliable kludges, you could hack the server
to give a 4xx and hope the client will try a different MXer.

A SMTP service extension could fix this properly. Let's call it
XREDIRECT, which is retured after EHLO on servers that wish to use
this capability. Feel free to remove all the vowels from the extension
name :)

A client that is XREDIRECT-aware can indicate this by putting it in
the MAIL (or RCPT?) command like so:

>>> MAIL FROM:<[EMAIL PROTECTED]> SIZE=1234 XREDIRECT
<<< 250 OK
>>> RCPT TO:<[EMAIL PROTECTED]> XREDIRECT
<<< 411 gb.example.net XREDIRECT
>>> RCPT TO:<[EMAIL PROTECTED]> XREDIRECT
<<< 250 OK
>>> DATA
[etc]

In the case where XREDIRECT cannot be negotiated, the server will just
have to accept and forward the message itself.

There's obviously a lot of work involved in deciding the exact
mechanism. Is gb.example.net looked up via MX, SRV, or something else?
Can clients cache the name, and for how long, or do they need to
initiate a new SMTP connection to the MXer for each new message, just
to be told to redirect? Would extending the MX lookup mechanism with
SRV records to direct to the correct server in the first place help?
What about the spam implications?

However, I figure that if it's useful, it'll end up in Exim et al and
eventually become supported on most major mail servers through natural
attrition.

Do I think it would be useful? Well, I'm not entirely sure. I suppose
it could be rather handy if ever email address portability becomes a
legal requirement and ISPs want to avoid bandwidth being sucked up by
ex-customers.

-- 
Love is not enough. It must be the foundation, the cornerstone- but not the
complete structure. It is much too pliable, too yielding.
- Quentin Crisp

Re: Localized mail servers, global scope

[Peter Corlett]

Andrew Staples <[EMAIL PROTECTED]> wrote:
> [...] the group wants to consolidate email addresses across the
> group, i.e.. [EMAIL PROTECTED], regardless of where the mail
> account lives, yet still give local control over the email server.

Due to the potential for namespace clashes, you *must* have a single
central organisation to manage the localpart namespace. MX records can
also only route mail on a domain basis, and not by localpart. Again,
this tends to drive centralisation.

[...]
> Has anyone got any other ideas on how to skin this cat with a
> technological solution not mentioned?

I would probably be tempted to just contract the whole lot out to a
third party that is not involved in your internal politics, including
maintaining a localpart registry.

The third party can then make a commercial decision as to the best way
to design the network is an complicated geographically load-balanced
cluster, or just to waste bandwidth and take a simpler system. Unless
they've got somebody CV-polishing, KISS will probably prevail as
bandwidth is cheap.

-- 
PGP key ID E85DC776 - finger [EMAIL PROTECTED] for full key

Please contribute to the beer fund and a tidier house:
http://search.ebay.co.uk/_W0QQfgtpZ1QQfrppZ25QQsassZpndc

Re: md5 for bgp tcp sessions

[Todd Underwood]

ras, all,

On Thu, Jun 23, 2005 at 12:14:12AM -0400, Richard A Steenbergen wrote:
> On Wed, Jun 22, 2005 at 10:04:09PM -0400, Todd Underwood wrote:

> > a) many (all?) implementations of md5 protection of tcp expose
> > new, easy-to-exploit vulnerabilities in host OSes.  md5 verification
> > is slow and done on a main processor of most routers.  md5
> > verification typically takes places *before* the sequence number,
> > ports, and ip are checked to see whether they apply to a valid
> > session.  as a result, you've exposed a trivial processor DOS to your
> > box.  
> 
> Well, I think they've finally fixed this one by now, at least everyone 
> that I'm aware of has done so. Immediately following the whining to start 
> deploying MD5 is was certainly the case that many implementations did 
> stupid stuff like process MD5 before running other validity checks like 
> sequence numbers which are far less computationally intensive, and there 
> were a few MSS bugs that popped up, but they should have all been worked 
> out by now. I don't think that anyone running modern code is suffering any 
> more attack potential because of this.

my understanding is that md5 is still checked before the ttl-hack
check takes place on cisco (and perhaps most router platforms).  new
attack vector for less security than you had before.  oh well.  ras:
can you confirm that it is possible to implement ttl-hack and have it
check *before* md5 signature checks?

the chaos (and crappy quality of the implementations) during the panic
demonstrates two other things:  rolling out magic code because your
vendor tells you to is a bad idea;  slapping together a hack on top of 
a well-designed protocol without careful thought and testing is a
terrible idea.  

t.

-- 
_
todd underwood
director of operations & security
renesys - interdomain intelligence
[EMAIL PROTECTED]   www.renesys.com

ISP phishing

[Gadi Evron]

Hi guys. I notice a large increase in recent weeks of ISP directed
phishing - largely because of worms moving backward to using the user's
own domain for the spam, but not just in the from: address.

I believe this started out as a "let's feel this out" or "wow, that
worked, let's phish ISP's directly too". I now have several reports that 
point to this becoming a serious problem.


Old with a spark of new, but definitely a problem.

Anyone else dealing with this?

Gadi.

Re: Localized mail servers, global scope

[Michael . Dillon]

> > 3.  Change company policy to reflect names like 
[EMAIL PROTECTED],
> > [EMAIL PROTECTED], etc, where DNS would resolve to the correct 
server.
> > Doesn't give corporate the "email image" they are after.

> unfortunately, all public routing to email servers is based only on 
domain
> names, so the domain name has to contain differential information if
> differential routing is needed.

In his case, it sounds like he actually has a business case
for solution 3 above. It only requires putting a dollar figure
on the cost of losing the partner relationship and some risk
percentages based on his own company being unreliable and a 
pain in the rear to work with. That should allow him to set
up the infrastructure which allows critical workers (such
as engineers exchanging CAD files) to use the region-specific
addresses.

--Michael Dillon

Re: Localized mail servers, global scope

[Michael . Dillon]

> You don't need a central MX if each site MTA knows which users are at
> which sites. Incoming email may have to take an extra hop if it comes in
> to the wrong site, but that's a consequence of the specification that no
> implementation can fix.

In other words, SMTP does not have the equivalent of an
HTTP redirect which is what he wants here. Maybe SMTP
really is broken? ;-)

--Michael Dillon