Re: The End-To-End Internet (was Re: Blocking MX query)

[Måns Nilsson]

Subject: Re: The End-To-End Internet (was Re: Blocking MX query) Date: Wed, Sep 
05, 2012 at 06:56:36PM -0400 Quoting William Herrin (b...@herrin.us):
 
> Thing is, spam levels *are* down a good 20% in the last couple years,
> that being about the time ISPs began doing this. More, 20% *is* in
> rough proportion the impacted customer counts on the handful of cable
> and DSL providers that implemented it.

Not here. My experience is that it is at best static, but most likely
increasing. Around here, the sad default is that it is impossible to
buy tcp/25 access except in colos and over tunnels. It does not help. It
just is a very bad precedent, it looks like you are doing something. Which
for lawyers is just as fine as efficient action.

We need to remind ourselves that this Internet thing got big simply
because it let people have computers send packets directly to other
peoples computers. There was this guy called Aesop who wrote a story
about blocking traffic on the Internet, but since the Internet wasn't
known at the time (too secret) he had to rephrase it so it became a
story about a goose that lays golden eggs.

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE +46 705 989668
I HAVE to buy a new "DODGE MISER" and two dozen JORDACHE JEANS because
my viewscreen is "USER-FRIENDLY"!!


signature.asc
Description: Digital signature

Re: The End-To-End Internet (was Re: Blocking MX query)

[Masataka Ohta]

Owen DeLong wrote:

>> then, if transport layer of the host is modified to perform
>> reverse translation (information for the translation can be
>> obtained through UPnP):
>>
>>  (local IP, global port) <-> (global IP, global port)
>>
>> Now, NAT is transparent to application layer.

> Never mind the fact that all the hosts trying to reach you have no
> way to know what port to use.

Quote from 

   A server port number different from well known ones may be specified
   through mechanisms to specify an address of the server, which is the
   case of URLs.

> http://www.foo.com fed into a browser has no way for the browser
> to determine that it needs to contact 192.0.200.50 on port 8099
> instead of port 80.

See RFC6281 and draft-ohta-urlsrv-00.txt.

But,

http://www.foo.com:8099

works just fine.

>> The remaining restrictions are that only TCP and UDP are supported
>> by UPnP (see draft-ohta-e2e-nat-00.txt for a specialized NAT box
>> to allow more general transport layers) and that a set of port
>> numbers available to the application layer is limited (you may
>> not be able to run a SMTP server at port 25).

> You're demanding an awful lot of changes to the entire internet to

All that necessary is local changes on end systems of those who
want the end to end transparency.

There is no changes on the Internet.

> This is every bit as much BS as it was the first 6 times you pushed it.

As you love BS so much, you should better read your own mails.

Masataka Ohta

Re: The End-To-End Internet (was Re: Blocking MX query)

[Cameron Byrne]

On Wed, Sep 5, 2012 at 9:39 PM, Owen DeLong  wrote:
>
> On Sep 5, 2012, at 21:08 , Masataka Ohta  
> wrote:
>
>> Jimmy Hess wrote:
>>
>>> NAT would fall under design flaw, because it breaks end-to-end
>>> connectivity, such that there is no longer an administrative choice
>>> that can be made to restore it  (other than redesign with NAT
>>> removed).
>>
>> The end to end transparency can be restored easily, if an
>> administrator wishes so, with UPnP capable NAT and modified
>> host transport layer.
>>
>
> This is every bit as much BS as it was the first 6 times you pushed it.
>

Yep.

Re: The End-To-End Internet (was Re: Blocking MX query)

[Owen DeLong]

On Sep 5, 2012, at 21:08 , Masataka Ohta  
wrote:

> Jimmy Hess wrote:
> 
>> NAT would fall under design flaw, because it breaks end-to-end
>> connectivity, such that there is no longer an administrative choice
>> that can be made to restore it  (other than redesign with NAT
>> removed).
> 
> The end to end transparency can be restored easily, if an
> administrator wishes so, with UPnP capable NAT and modified
> host transport layer.
> 

This is every bit as much BS as it was the first 6 times you pushed it.

> That is, the administrator assigns a set of port numbers to a
> host behind NAT and sets up port mapping.
> 
>   (global IP, global port) <-> (local IP, global port)
> 
> then, if transport layer of the host is modified to perform
> reverse translation (information for the translation can be
> obtained through UPnP):
> 
>   (local IP, global port) <-> (global IP, global port)
> 
> Now, NAT is transparent to application layer.
> 

Never mind the fact that all the hosts trying to reach you have no
way to know what port to use.

http://www.foo.com fed into a browser has no way for the browser
to determine that it needs to contact 192.0.200.50 on port 8099
instead of port 80.

> The remaining restrictions are that only TCP and UDP are supported
> by UPnP (see draft-ohta-e2e-nat-00.txt for a specialized NAT box
> to allow more general transport layers) and that a set of port
> numbers available to the application layer is limited (you may
> not be able to run a SMTP server at port 25).
> 

You're demanding an awful lot of changes to the entire internet to
partially restore IPv4 transparency when the better solution is to deploy
IPv6 and have real full transparency.

> The point of the end to end transparency is:
> 
>  The function in question can completely and correctly be
>  implemented only with the knowledge and help of the application
>  standing at the end points of the communication system.
> 

That is one purpose. A more accurate definition of the greater
purpose of end-to-end transparency would be:

An application can expect the datagram to arrive at the remote
destination without any modifications not specified in the basic
protocol requirements (e.g. TTL decrements, mac layer header
rewrites, reformatting for different lower-layer media, etc.)

An application should be able to expect the layer 3 and above
addressing elements to be unaltered and to be able to provide
"contact me on" style messages in the payload based on its own
local knowledge of its addressing.


> quoted from "End-To-End Arguments in System Design", the original
> paper on the end to end argument written by Saltzer et. al.
> 
> Thus,
> 
>  The NAT function can completely and correctly be
>  implemented with the knowledge and help of the host
>  protocol stack.
> 
>   Masataka Ohta
> 

It could be argued, if one considers "contact me on" style messages
to be valid, that the function cannot be completely and correctly
implemented in the presence of NAT.

Moreover, since NAT provides no benefit other than address
compression and the kind of additional effort on NAT of which you
speak would be a larger development effort than IPv6 at this point,
why bother?

Owen

Re: The End-To-End Internet (was Re: Blocking MX query)

[Masataka Ohta]

(2012/09/06 13:15), valdis.kletni...@vt.edu wrote:
> On Thu, 06 Sep 2012 13:08:29 +0900, Masataka Ohta said:
> 
>> The end to end transparency can be restored easily, if an
>> administrator wishes so, with UPnP capable NAT and modified
>> host transport layer.
> 
> How does the *second* host behind the NAT that wants to use
> global port 7719 do it?

In the previous mails, I wrote:

> The remaining restrictions are that ...
> and that a set of port
> numbers available to the application layer is limited (you may
> not be able to run a SMTP server at port 25).

and Jimmy wrote:

> At the transport layer, end-to-end means you can establish connections
> on various ports to any peer on the internet, and any peer can connect
> to all ports on which you allow.   It doesn't necessarily mean that
> all ports are allowed;  a remote host, or a firewall under their
> control, deciding to block your connection is not a violation of
> end-to-end.

Masataka Ohta

Re: The End-To-End Internet (was Re: Blocking MX query)

[valdis . kletnieks]

On Thu, 06 Sep 2012 13:08:29 +0900, Masataka Ohta said:

> The end to end transparency can be restored easily, if an
> administrator wishes so, with UPnP capable NAT and modified
> host transport layer.

How does the *second* host behind the NAT that wants to use
global port 7719 do it?


pgpgNE8JDz2TX.pgp
Description: PGP signature

Re: The End-To-End Internet (was Re: Blocking MX query)

[Masataka Ohta]

Jimmy Hess wrote:

> NAT would fall under design flaw, because it breaks end-to-end
> connectivity, such that there is no longer an administrative choice
> that can be made to restore it  (other than redesign with NAT
> removed).

The end to end transparency can be restored easily, if an
administrator wishes so, with UPnP capable NAT and modified
host transport layer.

That is, the administrator assigns a set of port numbers to a
host behind NAT and sets up port mapping.

(global IP, global port) <-> (local IP, global port)

then, if transport layer of the host is modified to perform
reverse translation (information for the translation can be
obtained through UPnP):

(local IP, global port) <-> (global IP, global port)

Now, NAT is transparent to application layer.

The remaining restrictions are that only TCP and UDP are supported
by UPnP (see draft-ohta-e2e-nat-00.txt for a specialized NAT box
to allow more general transport layers) and that a set of port
numbers available to the application layer is limited (you may
not be able to run a SMTP server at port 25).

The point of the end to end transparency is:

  The function in question can completely and correctly be
  implemented only with the knowledge and help of the application
  standing at the end points of the communication system.

quoted from "End-To-End Arguments in System Design", the original
paper on the end to end argument written by Saltzer et. al.

Thus,

  The NAT function can completely and correctly be
  implemented with the knowledge and help of the host
  protocol stack.

Masataka Ohta

Re: The End-To-End Internet (was Re: Blocking MX query)

[Jimmy Hess]

On 9/5/12, Sean Harlow  wrote:

> While I've clearly been on the side of "don't expect this to work", "why do
> you have your laptop set up like that?", and defending the default-blocking
> behavior on outbound, this is not true at least for Gmail.  I have a test
> Asterisk box which I've been really lazy about setting up properly that

I would still file it under... yes, there will probably be many mail
hosts you can contact that way. It will be understandable if many
block it,  but they don't have to.  If they give you a smart host,
then you should use that.

End-to-End doesn't imply control of the routing in-between smtp origin
and destination.

It will also be understandable if the ISP blocks outbound port 25, but
they don't have to.
Personally I would rather they not -- blocking port 25  doesn't make
the underlying problem go away;  it's just a way of  "hiding the
problem", so the ISP isn't pestered about it.


By blocking port 25; the ISP doesn't receive a spam complaint for
blocked non-legit activity, so they have fewer network abuse reports
to deal with.

Fewer users to turn off = fewer angered users switching to other providers
(Even if turning off the user in response to spam will help the user,
by alerting them to their compromised computer).

End user Having to use a smart relay host increases latency and
introduces a point of failure (ISP mail relay can fail or perform
unacceptably even when the network has no issues). If you have the
intelligence on your laptop to properly contact MX hosts;  the
restriction can be a hinderance,  and it is difficult to justify.


The ISP could block port 25 on report of abuse; but I suppose...
incident handlers' time reading abuse reports = $$$

Once the large ISPs do the math, it is understandable if their ISP
organizations' management eventually opts to block port 25.

For the ones who didn't choose to do that; presumably sufficient users
complained or they feared the competition would be strengthened or
charged  with their unpopular choice.


My idealistic preference would be the ISP allows outbound port 25,
but  are highly responsive to abuse complaints;   that way,  the
problem will be corrected,   instead of festering, until some day  the
laptop gets plugged into some network that happens to allow the port.

Or spreads the infection,  because of the port 25  block, the problem
goes undetected
and contributes to making the overall worse.

Just because a compromised host can't connect on port 25; doesn't mean
it is not a significant contribution to the problem.  Spreading
infection via other vectors;
spamming via other vectors such as IM,  Forum posts,  HTTP
contact/feedback forms...


There are plenty of abusive non port-25 activities  that ultimately
facilitate spamming.

--
-JH

Re: The End-To-End Internet (was Re: Blocking MX query)

[Sean Harlow]

On Sep 5, 2012, at 19:07, John Levine wrote:

> Not really.  Large mail system like Gmail and Yahoo have a pretty good
> map of the IPv4 address space.  If you're sending from a residential
> DSL or cable modem range, they'll likely reject any mail you send
> directly no matter what you do.

While I've clearly been on the side of "don't expect this to work", "why do you 
have your laptop set up like that?", and defending the default-blocking 
behavior on outbound, this is not true at least for Gmail.  I have a test 
Asterisk box which I've been really lazy about setting up properly that 
successfully sends status messages from my home cable modem to my Gmail-hosted 
personal domain every day, even getting through with a completely bogus source 
address.  It's never even been flagged as possible spam.

Maybe Gmail does more detailed analysis of some kind and sees that I'm also 
checking my email from the same IP that's sending these messages, I don't know, 
but they are not just blocking anything coming in from a random cable IP.  I'll 
bet it raises the "spam likelihood" or whatever as it probably should, but it's 
not a total block.
---
Sean Harlow
s...@seanharlow.info

Re: The End-To-End Internet (was Re: Blocking MX query)

[Jimmy Hess]

On 9/4/12, Jay Ashworth  wrote:
> It is regularly alleged, on this mailing list, that NAT is bad *because it
> violates the end-to-end principle of the Internet*, where each host is a
> full-fledged host, able to connect to any other host to perform
> transactions.
Both true.  and NAT inherently breaks the end-to-end principal for all
the applications.
Blocking port 25 traffic, also breaks the possibility of end-to-end
communications on that one port.

But not for the SMTP protocol.   SMTP End-to-End is preserved,  as
long as the SMTP relay provided does not introduce further
restrictions.


> We see it now alleged that the opposite is true: that a laptop, say, like
> mine, which runs Linux and postfix, and does not require a smarthost to
> deliver mail to a remote server *is a bad actor* *precisely because it does
> that* (in attempting to send mail directly to a domain's MX server) *from
> behind a NAT router*, and possibly different ones at different times.

Ding ding ding... behind a NAT router.   The  End-to-End principal is
already broken.
The 1:many NAT router prevents your host from being specifically
identified, in order to
efficiently and adequately identify,  report, and curtail abuse;  You
can't "break" the end-to-end principal in cases where it has already
been broken.

And selectively breaking end-to-end in limited circumstances is OK.
You choose to break it when the damage can be mitigated and the
concerns that demand breaking it are strong enough.


The end-to-end principal as you suggest primarily pertains to the
Internet protocol;  IP and TCP.  I believe you are trying to apply the
principal in an inappropriate way for the layer you are applying it
to.

At the SMTP application layer  end-to-end internet connectivity  means
 you can send e-mail to any e-mail address and receive e-mail from any
e-mail address.   For HTTP; that would mean  you can retrieve a page
from any host,  and any remote HTTP client,  can retrieve an page from
your hosts;   that doesn't necessarily imply that the transaction will
be allowed,  but  if it is refused --  it is for an administrative
reason,  not due to a design flaw.

NAT would fall under design flaw, because it breaks end-to-end
connectivity, such that there is no longer an administrative choice
that can be made to restore it  (other than redesign with NAT
removed).


At the transport layer, end-to-end means you can establish connections
on various ports to any peer on the internet, and any peer can connect
to all ports on which you allow.   It doesn't necessarily mean that
all ports are allowed;  a remote host, or a firewall under their
control, deciding to block your connection is not a violation of
end-to-end.

At the internet layer,  end-to-end means you can send any datagram to
any host on the internet it will be delivered to that host; and any
host can send a datagram to you.It doesn't mean that none of your
packets will be discarded on the way,  because some specific
application or port has been banned.

At the link layer,  there is no end-to-end connectivity;  it is at IP
that  the notion first arises.





> I find these conflicting reports very conflicting.  Either the end-to-end
> principle *is* the Prime Directive... or it is *not*.
>
> Cheers,
> -- jra
> --
> Jay R. Ashworth  Baylink
> j...@baylink.com
> Designer The Things I Think   RFC
> 2100
> Ashworth & Associates http://baylink.pitas.com 2000 Land Rover
> DII
> St Petersburg FL USA   #natog  +1 727 647
> 1274
>
>


-- 
-JH

Re: The End-To-End Internet (was Re: Blocking MX query)

[valdis . kletnieks]

On 05 Sep 2012 23:07:07 -, "John Levine" said:
> Not really.  Large mail system like Gmail and Yahoo have a pretty good
> map of the IPv4 address space.  If you're sending from a residential
> DSL or cable modem range, they'll likely reject any mail you send
> directly no matter what you do.

Which is why I finally gave up and speak to an 800 pound gorilla on port 587,
because nobody dares to mess with that gorilla's port 587 so  my laptop can
always get mail sent. :)


pgpurhUgUjkBA.pgp
Description: PGP signature

Re: The End-To-End Internet (was Re: Blocking MX query)

[John Levine]

>Well, if you've got proper forward and reverse DNS, and your portable 
>SMTP server identifies itself properly, and you are using networks that 
>don't filter outbound port 25, AND you have DKIM configured correctly 
>and aren't using it for a situation for which it is inappropriate, then 
>you'll get the same results with a portable SMTP server that you would 
>sending through a properly configured static server.

Not really.  Large mail system like Gmail and Yahoo have a pretty good
map of the IPv4 address space.  If you're sending from a residential
DSL or cable modem range, they'll likely reject any mail you send
directly no matter what you do.

R's,
John

Re: The End-To-End Internet (was Re: Blocking MX query)

[John Levine]

In article <5047a2ea.8010...@hup.org> you write:
>On 09/05/12 09:13 , Michael Thomas wrote:
>> The "I" part of DKIM is "Identified". That's all it promises. It's a
>> feature, not a bug, that spammers use it.
>
>Which is why DKIM does not really address any concerns.  The spammers
>have reduced its value.

Nothing personal, but nobody who had the most rudimentary
understanding of what DKIM does and how it's intended to be used would
make such a statement.

See the archives of the IETF DKIM list for much, much, much more detail.

R's,
John

Re: The End-To-End Internet (was Re: Blocking MX query)

[William Herrin]

On Wed, Sep 5, 2012 at 5:12 PM, Izaac  wrote:
> I suspect your ISP is also stripping  tags.  Let's try it out
> again:
>
>You can tell that tcp port 25 filtering is a highly effective spam
>mitigation technique because spam levels have declined in direct
>proportion to their level of deployment.  Today, we barely see any
>spam on the internet due to amazing ability of these filters to
>prevent bad people from sending bulk email.

Thing is, spam levels *are* down a good 20% in the last couple years,
that being about the time ISPs began doing this. More, 20% *is* in
rough proportion the impacted customer counts on the handful of cable
and DSL providers that implemented it.

And if you remind me that correlation is not causation I'll have to
point out the same flaw in your more sarcastic version.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Akamai Peering Tech

[Kris Amy]

Hi All,

If there is an Akamai peering tech around could they contact me
off-list regarding a BGP session which has been bouncing for a while.

Cheers,
Kris

Re: The End-To-End Internet (was Re: Blocking MX query)

[Cutler James R]

On Sep 5, 2012, at 5:12 PM, Izaac  wrote:
> 
>Since tcp25 filtering has been so successful, we should deploy
>   filters for everything except tcp80 and tcp443 and maaaybe tcp21 --
>   but NAT already does so much to enhance the user experience there
>   already.  And what with ISP customers using their provided DNS and
>   mail service exclusively, there's no reason to permit udp53, tcp110,
>   tcp143, tcp993, tcp995 either.  Really, only evil people use anything
>   but the web.  Any other traffic undoubtedly a bot from which they
>   ought to be protected.

Izaac,

You do realize that that the NANOG mailing is archived and some helpful person 
will quote you to their favorite legislator?

James R. Cutler
james.cut...@consultant.com

Re: RPKI Pilot Participant Notice

[Randy Bush]

>> [ hint: how does an isp in phnom penh validate my route? ]
> Your question is a bit cryptic.

moi?  :)

> Could you be more specific about your concern?

essentially, as the rirs have resisted iana being the root ta, the arin
tal is necessary for anyone to validate anything which dependa on the
arin data.  effectively you are requiring every router operator in the
world to sign your document.  does not work.

randy

Re: The End-To-End Internet (was Re: Blocking MX query)

[Izaac]

On Tue, Sep 04, 2012 at 03:45:32PM -0400, William Herrin wrote:
> That's what firewalls *are for* Jay. They intentionally break
> end-to-end for communications classified by the network owner as
> undesirable. Whether a particular firewall employs NAT or not is
> largely beside the point here. Either way, the firewall is *supposed*
> to break some of the end to end communication paths.

Which has had two basic results:

First, we've raised at least two generations of programmers who cannot
write a network-facing service able to stand up in so much as a stiff
breeze.  "Well it's behind the firewall, so no one will be able to see
it."

Second, we've killed -- utterly and completely -- countless promising
technologies and forced the rest to somehow figure out either how to
pretend to be HTTP or tunnel themselves.  That's just sad.

But even then, we're not talking about an end user choosing not to
permit certain kinds of inbound connectivity.  We're talking about
carriers inspecting and selectively interfering with (and in some cases
outright manipulating) communication in transit.  That's just plain
wrong.  

-- 
. ___ ___  .   .  ___
.  \/  |\  |\ \
.  _\_ /__ |-\ |-\ \__

Re: The End-To-End Internet (was Re: Blocking MX query)

[Joe St Sauver]

Izaac  commented:

#I suspect your ISP is also stripping  tags.  Let's try it out
#again:
#
#   You can tell that tcp port 25 filtering is a highly effective spam
#   mitigation technique because spam levels have declined in direct
#   proportion to their level of deployment.  Today, we barely see any
#   spam on the internet due to amazing ability of these filters to
#   prevent bad people from sending bulk email.
#
#Was that properly marked?

Actually, not sure sarcasm tags are appropriate.

1) Port 25 blocks target direct-to-MX spam delivered by bots.

2) The Spamhaus CBL tracks the level of bot spam currently seen,
including breaking out statistics by a number of factors.

3) Currently, the US, where port 25 filtering is routinely deployed by
most large ISPs, is ranked 158th among countries when you consider botted
users on a per capita basis: http://cbl.abuseat.org/countrypercapita.html

4) While that's not perfect (after all, there are still at least 133,811 
listings for the US), on a PER-CAPITA basis, it's not bad -- that's just 
~0.055% of US Internet users that are infected, relative to some countries 
where the rate of detected infection (based on spam emission) may be 4 to
5% or more.

So yes, actually, port 25 blocks *DO* tend to be effective in reducing 
bot-delivered email spam.

Does this mean that port 25 blocks are the ONLY measure that is required
to control spam? No, absolutely not. But it does clearly help.

Regards,

Joe

Re: RPKI Pilot Participant Notice

[Danny McPherson]

On Sep 5, 2012, at 3:32 PM, Gary Buhrmaster wrote:
> 
> My interpretation was what Randy implied, and that ARIN
> wants an agreement with everyone who gets a (presumably
> unique to the agreement) TAL to protect ARIN.  That would
> seem like a lot of overhead to maintain to me (since as I recall
> a TAL may never, ever (ok, very rarely) change), but then
> appropriate risk management has always been an interesting
> thing to watch in the (potentially litigious) ARIN region.

I'll let Randy speak for Randy (only he could do such a fine job).  

I do agree with Chris (and many others) that this whole thing falls apart 
pretty quickly without a single root (e.g., think of the browser CA problem) -- 
for many reasons.

I'd wager what ARIN is going to do in said "Relying Party Agreement" is tell 
RPs (i.e., *relying* parties) that they ought not rely to much on the data for 
routing, and if they do and something gets hosed, ARIN's not at fault -- but 
I'll wait to read the actual agreement before speculating more.

-danny

Re: The End-To-End Internet (was Re: Blocking MX query)

[Izaac]

On Wed, Sep 05, 2012 at 11:46:34AM -0400, Greg Ihnen wrote:
> On Wed, Sep 5, 2012 at 11:11 AM, Izaac  wrote:
> > On Wed, Sep 05, 2012 at 07:50:12AM -0700, Henry Stryker wrote:
> > > signature.  They are adaptive, like cockroaches.
> >
> > This is why tcp port 25 filtering is totally effective and will remain so
> > forever.  Definitely worth breaking basic function principles of a
> > global communications network over which trillions of dollars of commerce
> > occur.
>
> But as someone pointed out further back on this thread people who want to
> have their mail servers available to people who are on the other side of
> port 25 filtering just use the alternate ports. So then what does filtering
> port 25 accomplish?

I suspect your ISP is also stripping  tags.  Let's try it out
again:

   You can tell that tcp port 25 filtering is a highly effective spam
   mitigation technique because spam levels have declined in direct
   proportion to their level of deployment.  Today, we barely see any
   spam on the internet due to amazing ability of these filters to
   prevent bad people from sending bulk email.

Was that properly marked?  Or this one?

   Since tcp25 filtering has been so successful, we should deploy
   filters for everything except tcp80 and tcp443 and maaaybe tcp21 --
   but NAT already does so much to enhance the user experience there
   already.  And what with ISP customers using their provided DNS and
   mail service exclusively, there's no reason to permit udp53, tcp110,
   tcp143, tcp993, tcp995 either.  Really, only evil people use anything
   but the web.  Any other traffic undoubtedly a bot from which they
   ought to be protected.

-- 
. ___ ___  .   .  ___
.  \/  |\  |\ \
.  _\_ /__ |-\ |-\ \__

Re: The End-To-End Internet (was Re: Blocking MX query)

[Daniel Taylor]

On 09/05/2012 03:01 PM, Michael Thomas wrote:

On 09/05/2012 12:50 PM, Daniel Taylor wrote:


On 09/05/2012 10:19 AM, Michael Thomas wrote:

On 09/05/2012 05:56 AM, Daniel Taylor wrote:


On 09/04/2012 03:52 PM, Michael Thomas wrote:

On 09/04/2012 09:34 AM, Daniel Taylor wrote:
If you are sending direct SMTP on behalf of your domain from 
essentially random locations, how are we supposed to pick you out 
from spammers that do the same?




Use DKIM.
You say that like it's a lower bar than setting up a fixed SMTP 
server and using that.


I say it like it addresses your concern.


Well, if you've got proper forward and reverse DNS, and your portable 
SMTP server identifies itself properly, and you are using networks 
that don't filter outbound port 25, AND you have DKIM configured 
correctly and aren't using it for a situation for which it is 
inappropriate, then you'll get the same results with a portable SMTP 
server that you would sending through a properly configured static 
server.


So, no, "use DKIM" does not address the delivery difficulties 
inherent to using a portable SMTP server.



My how the goalposts are moving. DKIM solves the problem of producing
a stable identifier for a mail stream which is what your originally 
positioned

goalposts was asking for. It also makes reverse dns lookups even more
useless than they already are.
"Use your MX or SPF senders as your outbound mail agent, especially if 
they are properly configured with full DNS records so we can tell they 
are the correct machines to be sending on your behalf, or expect that 
you will get more mail bounced and lost  than the average user because 
you are being unpredictable and unverifiable."


That you so conveniently trimmed from the post that you replied to.

Just putting the goalposts back where I left them.

Proper DNS configuration is essential to reliable SMTP delivery. SPF and 
DKIM can help ensure you don't get mistakenly tagged as a spammer, but 
they are no substitute for proper technical configuration of your mail 
server, and you don't get proper configuration if you are using other 
people's networks.


--
Daniel Taylor VP Operations   Vocal Laboratories, Inc
dtay...@vocalabs.com 952-941-6580x203

Re: The End-To-End Internet (was Re: Blocking MX query)

[Michael Thomas]

On 09/05/2012 12:50 PM, Daniel Taylor wrote:


On 09/05/2012 10:19 AM, Michael Thomas wrote:

On 09/05/2012 05:56 AM, Daniel Taylor wrote:


On 09/04/2012 03:52 PM, Michael Thomas wrote:

On 09/04/2012 09:34 AM, Daniel Taylor wrote:

If you are sending direct SMTP on behalf of your domain from essentially random 
locations, how are we supposed to pick you out from spammers that do the same?



Use DKIM.

You say that like it's a lower bar than setting up a fixed SMTP server and 
using that.


I say it like it addresses your concern.


Well, if you've got proper forward and reverse DNS, and your portable SMTP 
server identifies itself properly, and you are using networks that don't filter 
outbound port 25, AND you have DKIM configured correctly and aren't using it 
for a situation for which it is inappropriate, then you'll get the same results 
with a portable SMTP server that you would sending through a properly 
configured static server.

So, no, "use DKIM" does not address the delivery difficulties inherent to using 
a portable SMTP server.


My how the goalposts are moving. DKIM solves the problem of producing
a stable identifier for a mail stream which is what your originally positioned
goalposts was asking for. It also makes reverse dns lookups even more
useless than they already are.

Mike

Re: The End-To-End Internet (was Re: Blocking MX query)

[Daniel Taylor]

On 09/05/2012 10:19 AM, Michael Thomas wrote:

On 09/05/2012 05:56 AM, Daniel Taylor wrote:


On 09/04/2012 03:52 PM, Michael Thomas wrote:

On 09/04/2012 09:34 AM, Daniel Taylor wrote:
If you are sending direct SMTP on behalf of your domain from 
essentially random locations, how are we supposed to pick you out 
from spammers that do the same?




Use DKIM.
You say that like it's a lower bar than setting up a fixed SMTP 
server and using that.


I say it like it addresses your concern.


Well, if you've got proper forward and reverse DNS, and your portable 
SMTP server identifies itself properly, and you are using networks that 
don't filter outbound port 25, AND you have DKIM configured correctly 
and aren't using it for a situation for which it is inappropriate, then 
you'll get the same results with a portable SMTP server that you would 
sending through a properly configured static server.


So, no, "use DKIM" does not address the delivery difficulties inherent 
to using a portable SMTP server.


--
Daniel Taylor VP Operations   Vocal Laboratories, Inc
dtay...@vocalabs.com 952-941-6580x203

Re: RPKI Pilot Participant Notice

[Gary Buhrmaster]

On Wed, Sep 5, 2012 at 7:24 PM, Christopher Morrow
 wrote:
.
> a closer (by me) reading of:
> " In order to access the
> production RPKI TAL, you will first have to agree to ARIN's Relying
> Party Agreement before the TAL will be emailed to you. To request the
> TAL after the production release, follow this link:
> http://www.arin.net/public/rpki/tal/index.xhtml";
>
> though kinda leads me into the hole randy/richard fell into... 'to
> poke the TAL and figure out where things are, you have to sign an
> agreement'.

My interpretation was what Randy implied, and that ARIN
wants an agreement with everyone who gets a (presumably
unique to the agreement) TAL to protect ARIN.  That would
seem like a lot of overhead to maintain to me (since as I recall
a TAL may never, ever (ok, very rarely) change), but then
appropriate risk management has always been an interesting
thing to watch in the (potentially litigious) ARIN region.

Gary

Re: RPKI Pilot Participant Notice

[Christopher Morrow]

On Wed, Sep 5, 2012 at 3:05 PM, Richard Barnes  wrote:
> I think Randy meant to imply that requiring anyone that wants to
> actually use the RPKI to make a legal agreement with ARIN might not be

define 'use'...

  o 'stick their objects into the repo' sure a contract sounds good
  o 'access the repo to download content' - no, that doesn't sound
like it needs a contract

is this a messaging problem/issue or did ARIN mean that 'to download
content you must sign an agreement/contract with ARIN?' (I hope that
the answer is: "of course not! that sounds silly... our messaging
could be improved")

a closer (by me) reading of:
" In order to access the
production RPKI TAL, you will first have to agree to ARIN's Relying
Party Agreement before the TAL will be emailed to you. To request the
TAL after the production release, follow this link:
http://www.arin.net/public/rpki/tal/index.xhtml";

though kinda leads me into the hole randy/richard fell into... 'to
poke the TAL and figure out where things are, you have to sign an
agreement'.

Isn't the structure of the global system something like:
  "each asn has a publication point, potentially some share
publication-points, everyone has to access everyone else's publication
point"

and 'TAL' ... seems like odd to me as an RP, don't I want the one TA
from IANA (yes, eventually) or at the very least the 1 from each RIR ?
(which is a simple single item to download and use in validating the
content I get from all the rest of the world?)

-chris

> the best way to encourage deployment.
>
>
> On Wed, Sep 5, 2012 at 2:56 PM, Mark Kosters  wrote:
>> On 9/5/12 3:26 AM, "Randy Bush"  wrote:
>>
>>>can you find the fatal flaw?
>>>
>>>[ hint: how does an isp in phnom penh validate my route? ]
>>>
>>>randy
>>
>> Hi Randy
>>
>> Your question is a bit cryptic. Could you be more specific about your
>> concern?
>>
>> Thanks,
>> Mark
>>
>>
>>
>

Re: The End-To-End Internet (was Re: Blocking MX query)

[Henry Stryker]

On 09/05/12 09:13 , Michael Thomas wrote:
> The "I" part of DKIM is "Identified". That's all it promises. It's a
> feature, not a bug, that spammers use it.

Which is why DKIM does not really address any concerns.  The spammers
have reduced its value.

I am retired now, but do run my own mail server from home.  It is a
challenge.  Not all static IP's provided by ISP's are outside of "home
IP groups", so you will find some of them blocked at some large domains.
 SPF and DKIM do help, a bit.  What I have found really makes the home
MTA possible are

1. a "real" static IP
2. proper DNS (A and PTR; PTR must at least exist)
3. tuning your MTA to respect the restraints of various large ISP's

Lacking 1 & 2, it is just not worth the effort attempting direct
delivery, if you value actual delivery of your email.  I would never
even attempt such from a peripatetic laptop.

Re: RPKI Pilot Participant Notice

[Richard Barnes]

I think Randy meant to imply that requiring anyone that wants to
actually use the RPKI to make a legal agreement with ARIN might not be
the best way to encourage deployment.


On Wed, Sep 5, 2012 at 2:56 PM, Mark Kosters  wrote:
> On 9/5/12 3:26 AM, "Randy Bush"  wrote:
>
>>can you find the fatal flaw?
>>
>>[ hint: how does an isp in phnom penh validate my route? ]
>>
>>randy
>
> Hi Randy
>
> Your question is a bit cryptic. Could you be more specific about your
> concern?
>
> Thanks,
> Mark
>
>
>

Tata Equinix

[Morgan Miskell]

Anyone on the list from Tata that can help address a Tata Equinix
Ashburn issue?
-- 
Morgan A. Miskell
CaroNet Data Centers
704-643-8330 x206

The information contained in this e-mail is confidential and is intended
only for the named recipient(s). If you are not the intended recipient
you must not copy, distribute, or take any action or reliance on it. If
you have received this e-mail in error, please notify the sender. Any
unauthorized disclosure of the information contained in this e-mail is
strictly prohibited.

Re: RPKI Pilot Participant Notice

[Mark Kosters]

On 9/5/12 3:26 AM, "Randy Bush"  wrote:

>can you find the fatal flaw?
>
>[ hint: how does an isp in phnom penh validate my route? ]
>
>randy

Hi Randy

Your question is a bit cryptic. Could you be more specific about your
concern?

Thanks,
Mark

Re: The End-To-End Internet (was Re: Blocking MX query)

[Michael Thomas]

On 09/05/2012 08:49 AM, Sean Harlow wrote:

2. The reason port 25 blocks remain effective is that there really isn't a 
bypass.


In the Maginot Line sense,  manifestly.

Mike

Re: The End-To-End Internet (was Re: Blocking MX query)

[Michael Thomas]

On 09/05/2012 07:50 AM, Henry Stryker wrote:
Not only that, but a majority of spam I receive lately has a valid DKIM signature. They are adaptive, like cockroaches. 


The "I" part of DKIM is "Identified". That's all it promises. It's a
feature, not a bug, that spammers use it.

Mike

Re: The End-To-End Internet (was Re: Blocking MX query)

[Sean Harlow]

On Sep 5, 2012, at 11:46, Greg Ihnen wrote:

> But as someone pointed out further back on this thread people who want to
> have their mail servers available to people who are on the other side of
> port 25 filtering just use the alternate ports. So then what does filtering
> port 25 accomplish?

The alternate port 587 is for users of that mail server to send mail through 
it, presumably authenticated, not for receipt of random mail from the internet. 
 This allows those users to relay email through their server unaffected while 
behind a port 25 block.  Configuring it to accept all messages on that port 
would defeat the purpose.
---
Sean Harlow
s...@seanharlow.info

Re: The End-To-End Internet (was Re: Blocking MX query)

[Sean Harlow]

On Sep 5, 2012, at 11:11, Izaac wrote:

> This is why tcp port 25 filtering is totally effective and will remain so
> forever.  Definitely worth breaking basic function principles of a
> global communications network over which trillions of dollars of commerce
> occur.

Two things to note:

1. Restricting outbound port 25 is nothing new.  It's been in use since before 
SPF or DKIM were under development, yet it hasn't been defeated/bypassed.  
Henry didn't specify whether the DKIM-valid messages he received were forged or 
if they just came from a random spam domain.  If the latter, of course that's 
trivial for spammers to make appear legitimate because the only goal of such 
systems is to verify that the sender controls or is approved by the domain the 
message claims to be from.

2. The reason port 25 blocks remain effective is that there really isn't a 
bypass.  If you want to spam, at some point you must establish a TCP connection 
to port 25 on the destination mail server.  You can either do this from your 
own machines (where a good hosting provider will cut you off in a hurry) or by 
using someone else's illegitimately.  Servers tend to be located in datacenters 
where again a good provider will take action, so botted end-user machines are 
obviously a huge thing to spammers.  Eliminate the ability for the majority of 
those bots to make said port 25 connections, you've now forced them in to a 
much smaller operating area where they're more likely to be found.  The only 
"bypass" is to go back to using their own machines or compromised equipment on 
higher-grade connections.

---
Sean Harlow
s...@seanharlow.info

Re: The End-To-End Internet (was Re: Blocking MX query)

[Greg Ihnen]

On Wed, Sep 5, 2012 at 11:11 AM, Izaac  wrote:

> On Wed, Sep 05, 2012 at 07:50:12AM -0700, Henry Stryker wrote:
> > Not only that, but a majority of spam I receive lately has a valid DKIM
> > signature.  They are adaptive, like cockroaches.
>
> This is why tcp port 25 filtering is totally effective and will remain so
> forever.  Definitely worth breaking basic function principles of a
> global communications network over which trillions of dollars of commerce
> occur.
>
> --
> . ___ ___  .   .  ___
> .  \/  |\  |\ \
> .  _\_ /__ |-\ |-\ \__
>
>
But as someone pointed out further back on this thread people who want to
have their mail servers available to people who are on the other side of
port 25 filtering just use the alternate ports. So then what does filtering
port 25 accomplish?

Greg

Re: Level 3 BGP Advertisements

[Marc Storck]

>Just for kicks, I tried using a .0.0/16 and .255.255/16 adress for stuff
>in IOS (configured it as loopback and tried to establish bgp sessions
>etc), that didn't work so well. I don't remember exactly what the problem
>was, but I did indeed run into problems.

LU-CIX uses .255 and .0 for their route servers. See [1]. And it looks
like most router fabrics can now handle BGP sessions to those addresses.

Regards,

Marc

[1] http://www.lu-cix.lu/route-servers.html 


smime.p7s
Description: S/MIME cryptographic signature

Re: The End-To-End Internet (was Re: Blocking MX query)

[Michael Thomas]

On 09/05/2012 05:56 AM, Daniel Taylor wrote:


On 09/04/2012 03:52 PM, Michael Thomas wrote:

On 09/04/2012 09:34 AM, Daniel Taylor wrote:

If you are sending direct SMTP on behalf of your domain from essentially random 
locations, how are we supposed to pick you out from spammers that do the same?



Use DKIM.

You say that like it's a lower bar than setting up a fixed SMTP server and 
using that.


I say it like it addresses your concern.

Mike

Re: The End-To-End Internet (was Re: Blocking MX query)

[Izaac]

On Wed, Sep 05, 2012 at 07:50:12AM -0700, Henry Stryker wrote:
> Not only that, but a majority of spam I receive lately has a valid DKIM
> signature.  They are adaptive, like cockroaches.

This is why tcp port 25 filtering is totally effective and will remain so
forever.  Definitely worth breaking basic function principles of a
global communications network over which trillions of dollars of commerce
occur.

-- 
. ___ ___  .   .  ___
.  \/  |\  |\ \
.  _\_ /__ |-\ |-\ \__

Re: The End-To-End Internet (was Re: Blocking MX query)

[Henry Stryker]

On 09/05/12 05:56 , Daniel Taylor wrote:
>> Use DKIM.
> You say that like it's a lower bar than setting up a fixed SMTP server
> and using that.
> Besides, doesn't DKIM break on mailing lists?

Not only that, but a majority of spam I receive lately has a valid DKIM
signature.  They are adaptive, like cockroaches.

Re: Blocking MX query

[David Barak]

On Sep 4, 2012, at 11:45 PM, Suresh Ramasubramanian  wrote:
> 
> So - now with ipv6 you're going to see "hi, my toto highly
> computerized toilet is trying to make outbound port 25 connections to
> gmail"
> 
> http://www.telecoms.com/48734/vodafone-and-ibm-team-up-on-connected-home-appliances/
> 
> -- 
> Suresh Ramasubramanian (ops.li...@gmail.com)
> 

Gives a new meaning to a sh*** connection.  Or perhaps to flushing a mail 
queue...

David

Sent from a mobile device, please forgive autocorrection.

Re: The End-To-End Internet (was Re: Blocking MX query)

[Daniel Taylor]

On 09/04/2012 03:52 PM, Michael Thomas wrote:

On 09/04/2012 09:34 AM, Daniel Taylor wrote:
If you are sending direct SMTP on behalf of your domain from 
essentially random locations, how are we supposed to pick you out 
from spammers that do the same?




Use DKIM.
You say that like it's a lower bar than setting up a fixed SMTP server 
and using that.

Besides, doesn't DKIM break on mailing lists?

--
Daniel Taylor VP Operations   Vocal Laboratories, Inc
dtay...@vocalabs.com 952-941-6580x203

Re: 91.201.64.0/22 hijacked?

[Georgios Theodoridis]

I was wondering if there is a repository with references of prefix 
hijack cases.
We would like to use such information for a BGP anomaly detection 
analysis that we are carrying out in our research centre.
Unfortunately, apart from the well known cases (Youtube-Pakistan case in 
2008 and the China case in 2010, neither of which is an actual hijack, 
since they both took place due to misconfigurations and not due to 
malicious cyber attacks) there is lack of ground truth information that 
can be used for the validation of our techniques.


Thank you very much in advance,

George
.
On 4/9/2012 11:34 ??, Schiller, Heather A wrote:

It does not sound as though the original holders of the space know/care - if 
they are out of business, they probably don't care.  If they are actively 
involved in it, then it's not a hijack.  If they haven't updated their company 
name/website, then it's not a hijack, just poor record keeping.

If you suspect the address space is abandoned, or hijacked, report it to RIPE.  
It may not get deallocated and reassinged until a few months after the bill 
stops getting paid.

  --Heather

-Original Message-
From: Jeroen van Aart [mailto:jer...@mompl.net]
Sent: Friday, August 31, 2012 2:39 PM
To: NANOG list
Subject: 91.201.64.0/22 hijacked?

The below email exchange may be of interest to some of you. The practical upshot is that 
it appears "the 91.201.64.0/22 range was hijacked and should be included into the 
DROP list".

As an interesting aside, quoting a friend:

"the original company (that performed dangerous waste utilization) may have been a shady thing in and of 
itself (..) what most companies calling themselves "ecoservice" (with variations) do is take money 
for "safe utilisation" of hazardous waste, and then dump it in some old quarry out in the remote 
(or not so remote) corner of a forest or other natural area (..) they always have criminal links and 
protection from corrupts officials (often co-owners) and security/law enforcement services"



From: Jeroen van Aart
there is
nothing but crap coming from 91.201.64.0/24. Amongst other things
attempts to spam (through) wordpress sites.
inetnum: 91.201.64.0 - 91.201.67.255
netname: Donekoserv
descr:   DonEkoService Ltd

Don - name of the nearby large river.
"EkoService" means ecological service.


country: RU
org: ORG-DS41-RIPE

person: Haralevich Piotr
address:novocherkassk, ul stremyannaya d.6
mnt-by: MNT-DONECO
phone:  +7495100

nic-hdl: HP2220-RIPE
changed: ad...@donecoserv.ru 20101117

The company performed dangerous waste utilization:
http://donekoservis.alloy.ru/contacts/
http://www.idbo.ru/view/72321/
But domains donecoserv.ru and donekoservis.ru don't exist anymore.

traceroute 91.201.64.14
...
11 router02.spbbm18.ru.edpnet.net (212.71.11.26) 65.979 ms 65.971 ms
66.182 ms
12 77.109.110.62.static.edpnet.net (77.109.110.62) 88.868 ms 47.809 ms 47.715ms
13 195.2.240.234 (195.2.240.234)  48.235 ms  48.546 ms  48.664 ms
14 ajursrv.parohod.biz (95.215.0.206)  47.957 ms  47.752 ms  47.606 ms
15 mail.rx-helps.com (91.201.64.14)  48.206 ms  48.302 ms  48.237 ms

SPb (Sankt-Peterburg) is 1500 km from Novocherkassk.
parohod.biz also is in Sankt-Peterburg, they offer SEO (which I consider fraud, 
spamming websites and search engines).

Also, see
http://support.clean-mx.de/clean-mx/viruses.php?email=ad...@donecoserv.ru&response=
http://www.spambotsecurity.com/forum/viewtopic.php?f=7&t=795

http://unapprovedpharmacy.wordpress.com/2011/01/03/whois-www-canadianmedsshop-com/
| January 3, 2011
...
| inetnum: 91.201.64.0  91.201.67.255
| netname: Donekoserv
| descr: DonEkoService Ltd
| country: RU
| org: ORG-DS41-RIPE
...
| organisation: ORG-DS41-RIPE
| org-name: DonEko Service
| org-type: OTHER
| address: novocherkassk, ul stremyannaya d.6
| e-mail: ad...@bulletproof-web.com

Note "bulletproof".

Therefore, the 91.201.64.0/22 range was hijacked and should be included into 
the DROP list.

Fwd: RPKI Pilot Participant Notice

[Randy Bush]

can you find the fatal flaw?

[ hint: how does an isp in phnom penh validate my route? ]

randy

--- Begin Message ---
Our records indicate that you have requested and received access to
ARIN's RPKI Pilot. ARIN is preparing to release our production RPKI
hosted solution in mid to late September of this year. This release will
trigger two events: the pilot will be immediately decommissioned, and
the pilot RPKI repository will be shutdown a few days later. As noted in
the welcome message, none of the ROA's that you placed in the pilot will
be transferred into the production system.

If you are also a relying party and have a validator, the Trust Anchor
Locator (TAL) for ARIN's production system is different than the one you
have been using during the ARIN RPKI pilot. In order to access the
production RPKI TAL, you will first have to agree to ARIN's Relying
Party Agreement before the TAL will be emailed to you. To request the
TAL after the production release, follow this link:
http://www.arin.net/public/rpki/tal/index.xhtml

This service will be available through ARIN Online, so we encourage you
to set up your account and link to your organizations network resources
so that you can join the production RPKI system by requesting ARIN to
certify your resources as soon as it is released.

Regards,


Mark Kosters
Chief Technical Officer
American Registry for Internet Numbers (ARIN)


--- End Message ---