Re: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability

[Mark Tinka]

On Friday, March 28, 2014 05:48:29 AM Shrdlu wrote:

> Why? Personally, I think it's fine. It only happens (at
> most) every six months (and sometimes more like a year).

I think it's fine too.

As I'm sure you know, if you're a Cisco customer, you can 
subscribe to their internal notification services where 
you'll get this anyway.

That they consolidate the most critical bug information and 
push it out to the typical operational mailing lists a 
couple of times a year is not such a problem, I'd say. For 
some, this could be the only way they find out.

Mark.


signature.asc
Description: This is a digitally signed message part.

Re: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal)

[Mark Tinka]

On Thursday, March 27, 2014 11:27:26 PM Randy Bush wrote:

> e.g. the database working group covers what you think of
> as whois and the routing registry.  the wg developed the
> darned irr definition and continues to evolve it. 
> consequence?  the irr is actively used in two regions in
> the world, europe and japan (which likes anything
> ocd:-).

The RIPE IRR is used very widely in the Africa region, too.

Great toolset.

Mark.


signature.asc
Description: This is a digitally signed message part.

Re: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal)

[Owen DeLong]

I, for one, would not want to start having to pay RIPE-level fees.

ARIN fees are a much better deal than RIPE fees.

Owen

On Mar 27, 2014, at 3:10 PM, Cb B  wrote:

> On Mar 27, 2014 3:03 PM, "John Curran"  wrote:
>> 
>> And I would welcome discussion of how ARIN (and nanog) can be more like
> RIPE - that is very much up to this community and its participation far
> more than ARIN..
>> 
>> /John
>> 
> 
> How about we fold ARIN into RIPE? Why not? I agree with all of Randy's
> points. I am sure RIPE can easily scale up to take on ARIN services, with
> fees being reduced for all involved due to economies of scale.
> 
> CB
> 
>>> On Mar 28, 2014, at 5:27 AM, Randy Bush  wrote:
>>> 
>>> john,
>>> 
>>> i think your attemt to move the discussion to the arin ppml list
>>> exemplifies one core of the problem.  this is not about address policy,
>>> but arin thinks of itelf as a regulator not a registry.
>>> 
>>> contrast with the ripe community and the ncc, which is not nirvana but
>>> is a hell of a lot better.  among other key differences, the ncc is
>>> engaged with the community through technical and business working
>>> groups.
>>> 
>>> e.g. the database working group covers what you think of as whois and
>>> the routing registry.  the wg developed the darned irr definition and
>>> continues to evolve it.  consequence?  the irr is actively used in two
>>> regions in the world, europe and japan (which likes anything ocd:-).
>>> 
>>> the routing wg works with the ops to develop routing technology such as
>>> route flap damping.  there is a reason that serious ops attend ripe
>>> meetings.  yes, a whole lot of folk with enable are engaged.
>>> 
>>> for years there has been a wg on the global layer nine issues.
>>> 
>>> the dns wg deals with reverse delegation, root server ops, etc.  and
>>> guess what, all the dns heavy techs and ops are engaged.
>>> 
>>> there is a wg for discussing what services the ncc offers.  the recent
>>> simplification and opening of services to legacy and PI holders happened
>>> in the ncc services wg, it was about services not addressing policy.
>>> 
>>> and this is aside from daniel's global measurement empire.  not sure it
>>> is a registry's job to do this, but it is a serious contribution to the
>>> internet.
>>> 
>>> the ncc is engaged with its community on the subhects that actually
>>> interest operators and affect our daily lives.
>>> 
>>> there is nothing of interest at an arin meeting, a bunch of junior
>>> wannabe regulators and vigilantes making an embarrassing mess.  i've
>>> even taken to skipping nanog, if ras talks i can watch the recording.
>>> all the cool kids will be in warsaw.  ops vote with our feet.
>>> 
>>> randy
>>> 
>> 

Re: IPv6 Security

[Owen DeLong]

On Mar 27, 2014, at 1:55 PM, Karl Auer  wrote:

> On Thu, 2014-03-27 at 05:34 -0700, Owen DeLong wrote:
>> What do you think “Link Layer Address” (RFC 3315, Section 9.1 Type 3)
>> is? From RFC-3315 Section 9.4, it seems pretty clear that is exactly what
>> this is intended to be. True, it includes an additional 16 bits of media 
>> type,
>> but I don’t see that as being a problem.
> 
> Though to be fair 3315 also says that the DUID should be treated as an
> opaque blob, not parsed and bits extracted from it. From section 9:
> 
>   "Clients and servers MUST treat DUIDs as opaque values
>and MUST only compare DUIDs for equality. Clients and
>servers MUST NOT in any other way interpret DUIDs."
> 
> Regarding section 9.4, which you refer to: 3315 only uses MACs to
> *construct* useful DUIDs, not as a means of communicating MACs to
> clients or servers. Also, an operator cannot RELY on getting a MAC
> address in a DUID.
> 
> DUID's *are* different and *do* require new ways of doing things. People
> will work it out.

Right… The comment wasn’t about getting the Mac address, the comment was about
having a DUID that remains the same across reboots and software installations.

Using LL (type 3) DUIDs should accomplish that.

Linking your IPv4 DHCP System ID and your IPv6 DHCP System ID is a completely
different problem which I don’t see much practical purpose for other than by 
the hostname
which could easily be handled in the DDNS registration process.

Owen

Re: why IPv6 isn't ready for prime time, SMTP edition

[Owen DeLong]

On Mar 27, 2014, at 1:38 PM, Brandon Ross  wrote:

> On Thu, 27 Mar 2014, Owen DeLong wrote:
> 
>> On Mar 27, 2014, at 11:15 AM, Barry Shein  wrote:
>> 
>> Please explain in detail where the fraud potential comes in.
> 
> Spammer uses his botnet of zombie machines to send email from each of them to 
> his own domain using the user's legitimate email address as From:. Spammer 
> says it was unsolicited and keeps the full $.10/email that victim users have 
> deposited into this escrow thing.
> 
> Sounds a lot more profitable than regular spam.

You say this like having a tax on running a botted computer on the internet 
would be a bad thing.

I agree that it would provide a bit of profit to the spammers for a very short 
period of time, but I bet it would get a lot of bots fixed pretty quick.

Owen

Re: why IPv6 isn't ready for prime time, SMTP edition

[Barry Shein]

On March 27, 2014 at 12:14 o...@delong.com (Owen DeLong) wrote:
 > 
 > On Mar 27, 2014, at 11:15 AM, Barry Shein  wrote:
 > 
 > > 
 > > On March 26, 2014 at 22:25 o...@delong.com (Owen DeLong) wrote:
 > >> 
 > >> Actually, a variant on that that might be acceptable? Make e-postage a 
 > >> deposit-based thing. If the recipient has previously white-listed you or 
 > >> marks your particular message as ?desired?, then you get your postage 
 > >> back. If not, then your postage is put into the recipients e-postage 
 > >> account to offset the cost of their emails.
 > >> 
 > >> Thoughts?
 > > 
 > > It's a fine idea but too complicated.
 > > 
 > > Look, the (paper) post office doesn't say "oh, you WANTED that mail,
 > > ok, then we'll return the cost of postage to the sender!"
 > > 
 > > Why? Because if they did that people would game the system, THEY'D
 > > SPAM!
 > 
 > How would they benefit from that?

>From what, being able to send free paper mail? I think that would be
considered a benefit by most junk mail advertisers. But see next...

 > SPAM ? Pay, say $0.10/message.
 > Then Claim you wanted the SPAM, get your $0.10/message back for each SPAM 
 > you sent to yourself.
 > Or, claim you didn?t want the SPAM and get $0.05/message for each message 
 > you received while the
 > original provider keeps the other $0.05.
 > 
 > > And it would take way too much bookkeeping and fraud identification etc.
 > 
 > Please explain in detail where the fraud potential comes in.
 > 
 > By my interpretation, you?d have to somehow get more back than you deposited 
 > (not really possible) in order to profit from sending SPAM this way.

Well, it's advertising, so they do.

Advertising is a valuable commodity.  Free advertising is particularly
valuable, ROI with I close to zero.

Look, we can get lost in metaphors, but the point is that by the time
the post office gets your mail to your doorstep virtually all the cost
is sunk.

So offering to not charge you because you wanted that mail makes no
sense, right?

 > > Let's take a deep breath and re-examine the assumptions:
 > > 
 > > Full scale spammers send on the order of one billion msgs per day.
 > > 
 > > Which means if I gave your account 1M free msgs/day and could
 > > reasonably assure that you can't set up 1,000 such accts then you
 > > could not operate as a spammer.
 > 
 > Not sure how you enforce these user account requirements or how you avoid 
 > duplicative accounts.

If you want to attach e-postage you have to go get some and that can
be a contract which says you don't do that, if you have multiple
accounts you split it among your accounts or buy more. And if you do
what you describe you understand that it is criminal fraud. Click
Agree [ ] before proceeding, or similar.

 > 
 > > Who can't operate with 1M msgs/day?
 > > 
 > > Well, maybe Amazon or similar.
 > > 
 > > But as I said earlier MAYBE THEY SHOULD PAY ALSO!
 > 
 > I, for one, don?t want my Amazon prices increased by a pseudo-tax on the 
 > fact that they do a large volume of email communications with their 
 > customers. They have enough problems trying to get IPv6 deployed without 
 > adding this to their list of problems.

That assumes that spam is free for them, and you. Including "free" as
in "stealing your time".

Also, companies like Amazon probably wouldn't mind being able to
out-capitalize spammers and others in competing for your eyeballs.

They could probably put a price on that.

They're well aware that when they send you an email that says that
some new book related to one you bought is available that the ad is
surrounded by dozens if not hundreds of spam messages and likely
you'll delete them all without reading.

So that's already a cost to them in terms of wasted advertising effort
and lost sales.

I'd say we need to ask Amazon et al whether they'd see it as an
economic plus if by paying a small amount of e-postage they could wipe
out or seriously reduce all the chaff?  Would that be a net positive
or net negative to their bottom line?

Although I can certainly understand skepticism about whether this
approach would deliver effectively I don't think the business case,
the dollar value of reducing spam significantly, is disputable.

You'd always rather be the only billboard on the highway rather than
just one in a hundred. Even if it costs you more (obviously up to a
point.)

 > 
 > > We really need to get over the moral component of spam content (and
 > > senders' intentions) and see it for what it is: A free ride anyone
 > > would take if available.
 > 
 > I disagree. I see it as a form of theft of service that only immoral thieves 
 > would take if available.

How can it be a theft of service if we're not charging anything?

Well, if they use others' resources it's a theft of those resources,
such as botnets, is that what you mean?

But by morality I mean that we tend to define spam in terms of
generally agreed to be undesirable email content such as questionable
herbal cures or other 

Re: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability

[Peter Kristolaitis]

On 3/28/2014 12:57 AM, Randy Bush wrote:

Alexander Neilson  wrote:

I wonder if they should be invited to only post a single message with
the titles and links to the alerts so that people can follow it up.

i would prefer that the header be in blue, the titles in green, and the
urls in magenta, in comic sans, of course

randy



I disagree vehemently.  That's far too simple of a system and doesn't 
convey the necessary information that should be in a summary document.


Titles should be either cerise, amaranth or raspberry coloured, 
depending on the bug's severity, and the headers should be blue-gray, 
glaucous or steel blue depending on the day of the week the bug was 
discovered.  Some people might whine that those colors are too close to 
each other, but they can just buy a colorimeter -- that's an operational 
problem anyways.


I can agree to comic sans, as long as it blinks.

Actually, we should probably just set up a committee for report 
styling.  We really need an industry standard for this, and one that 
covers all possible reporting needs for at least the next 20 years.   
Shouldn't take more than a few weeks.


I think I have a TPS report template around here that would be a great 
starting point   :p

Re: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability

[Larry Sheldon]

On 3/27/2014 11:57 PM, Randy Bush wrote:

Alexander Neilson  wrote:

I wonder if they should be invited to only post a single message with
the titles and links to the alerts so that people can follow it up.


i would prefer that the header be in blue, the titles in green, and the
urls in magenta, in comic sans, of course


I prefer flat ASCII text.  That will shut most of them up.


--
Requiescas in pace o email   Two identifying characteristics
of System Administrators:
Ex turpi causa non oritur actio  Infallibility, and the ability to
learn from their mistakes.
  (Adapted from Stephen Pinker)

Re: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability

[Randy Bush]

Alexander Neilson  wrote:
> I wonder if they should be invited to only post a single message with
> the titles and links to the alerts so that people can follow it up.

i would prefer that the header be in blue, the titles in green, and the
urls in magenta, in comic sans, of course

randy

Re: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability

[Shrdlu]

On 3/27/2014 7:44 PM, Alexander Neilson wrote:

I wonder if they should be invited to only post a single message with
the titles and links to the alerts so that people can follow it up.


Why? Personally, I think it's fine. It only happens (at most) every six
months (and sometimes more like a year).


Depends on compliance with the charter for the list but I think it
might be nice list etiquette.


I'm surprised at the level of concern over this, considering it's an
event that has been going on since before most of those posting about
this were even on this list. I'm hoping (in vain, I'm sure) that my
gently pointing out that those posts are useful to many people, and
that their occurrence predates most of you, will make this non-issue
die away (and you make me REALLY MISS srh).

While I still worked (I don't now; I'm retired), it was nice to have
those alerts, because it could be checked against the *things* *that*
*should* *be* *patched* for sanity. Even now, there's still Cisco stuff
on my toy network, and I *still* care.

Could we just stick to the interesting issues of IPv6, and SMTP, and
move on? Please?

--
You've confused equality of opportunity for equality of outcomes,
and have seriously confused justice with equality.
(Woodchuck)

Re: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability

[Alexander Neilson]

I wonder if they should be invited to only post a single message with the 
titles and links to the alerts so that people can follow it up.

They should also include a link to their own list that they send the full 
alerts to.

That way there could be some headline alerting to people that there is 
something in that topic available but avoids sending each alert to the list 
every time.

Depends on compliance with the charter for the list but I think it might be 
nice list etiquette.

Regards
Alexander

On 28/03/2014, at 3:27 pm, Larry Sheldon  wrote:

> On 3/27/2014 4:07 PM, Matt Palmer wrote:
>> On Wed, Mar 26, 2014 at 10:52:42AM -0600, kendrick eastes wrote:
>>> The Full-disclosure mailing list was recently... retired, I guess cisco
>>> thought NANOG was the next best place.
>> 
>> Nope, they've been sending these things here for as long as I can remember.
>> I have NFI why -- probably hubris, thinking that everyone running a network
>> *must* have some Cisco somewhere.
> 
> There used to be cisco 'wigs with well-known names on NANOG.
> 
> One of them was probably asked to do it.
> 
> 
> 
> -- 
> Requiescas in pace o email   Two identifying characteristics
>of System Administrators:
> Ex turpi causa non oritur actio  Infallibility, and the ability to
>learn from their mistakes.
>  (Adapted from Stephen Pinker)
> 

Re: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability

[Larry Sheldon]

On 3/27/2014 4:07 PM, Matt Palmer wrote:

On Wed, Mar 26, 2014 at 10:52:42AM -0600, kendrick eastes wrote:

The Full-disclosure mailing list was recently... retired, I guess cisco
thought NANOG was the next best place.


Nope, they've been sending these things here for as long as I can remember.
I have NFI why -- probably hubris, thinking that everyone running a network
*must* have some Cisco somewhere.


There used to be cisco 'wigs with well-known names on NANOG.

One of them was probably asked to do it.



--
Requiescas in pace o email   Two identifying characteristics
of System Administrators:
Ex turpi causa non oritur actio  Infallibility, and the ability to
learn from their mistakes.
  (Adapted from Stephen Pinker)

Re: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal)

[John Curran]

On Mar 28, 2014, at 6:42 AM, Randy Bush  wrote:
> ...
> i purposefully phrased it a bit differently, how can arin engage, get
> real participation from, and serve its community, the operators.  i was
> stealing examples from ripe.
> 
> but, for concrete action, how about a half day session at the next nanog
> meeting on, for example, arin database services, whois and irr.  not to
> try to reach hard conclusions or plans.  but to open a dialog to explore
> what the community gets and wants from these services and how they are
> provided.

My earlier message was sent before I saw this, but I think we converged 
on the important point: ARIN needs to engage in a much better manner with 
the ops community (more than just an ARIN update preso and registration 
helpdesk); this should be closer to a "services wg" model.

Got it,
/John

John Curran
President and CEO
ARIN

Re: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal)

[Majdi S. Abbas]

On Fri, Mar 28, 2014 at 02:04:30AM +, John Curran wrote:
> Internet routing registries are a fine example; one could argue that 
> it should be integrated with the number resource registry, but we also 
> have examples of independent routing registries in active use (and I
> can see some potential reasons why operators might even want there to
> be a healthy separation between those functions.)

Speaking for myself, only here:

I'll be happy to let ARIN manage routability of assignments, 
once they guarantee routability of said assignments.

Cheers,

--msa

Re: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal)

[John Curran]

On Mar 28, 2014, at 6:04 AM, Randy Bush  wrote:
> i will refrain from characterizing the ppml list.  needless to say, i do
> not subscribe.
> 
> my point is that what arin does should be of interest to nanog
> subscribers.  in theory, the ops are the arin community, the registry
> serves operations.  if it is not of interest to ops, it is not serving
> the community.

I fully agree, but also respect that this community has made some 
conscience decisions regarding having ARIN be quite registry focused 
and letting NANOG evolve as as a forum of the operators in the region.  
I believe that several of the initiatives that you noted from the RIPE 
region could easily be viewed as falling under either organization.   

This community should not be disadvantaged by the structure of having 
a distinct registry and distinct operator forum, but it does mean that
we need to be able to sort out _what_ the operators want and then where 
it gets done.

Internet routing registries are a fine example; one could argue that 
it should be integrated with the number resource registry, but we also 
have examples of independent routing registries in active use (and I
can see some potential reasons why operators might even want there to
be a healthy separation between those functions.)

If the community has one mind of what routing registry capabilities is
wants here, including how it wants it governed and operated, I am quite 
certain that ARIN will support the direction, regardless of where it ends 
up being operated and how it ends up being governed.  The lack I have 
noted over the years is lack of clear direction from the community, but 
that should not be something "ARIN" jumps in and tries to bring about - 
it needs to be of interest to (and led by) the operators on this list.

We agree that ARIN needs to be relevant to the ops community, and I am
very open minded to any suggestions you have, but don't exactly think 
that your examples from RIPE are necessarily where we want ARIN to go 
as much as things we want to have happen, whether that's ARIN, NANOG, 
or other associated organizations.  On the other hand, your governance 
examples from RIPE (e.g. "wg for discussing what services the ncc 
offers") are directly on target, and I will share them on some other 
lists that may defy characterization by you.

> [ get out of s'pore yet?  drc got delayed a day with a missing part for
>  his plane! ]

(Getting closer... the last plane was a fail due to fuel pump issues; 
my dearest friends at United seemed have rerouted me through Hong Kong 
but omitted a flight onward.  Oh well.)

Thanks!
/John

Re: IPv6 isn't SMTP

[Dave Crocker]

On 3/27/2014 6:51 AM, Blake Hudson wrote:

The primary issues I see with SMTP as a protocol related to the lack of
authentication and authorization. Take, for instance, the fact that the
SMTP protocol requires a mail from: and rcpt to: address (more or less
for authentication and authorization purposes),


Actually, for neither.

Mail from was mislabeled; it merely provides an address to send return 
notices to, which is why it makes sense to permit it to be different 
from the rfc5322.From value.  And, of course, rcpt to specifies a 
recipient address.


auth/auth functions were tacked on much, much later, which is why their 
utility is so constrained. (20 years?)




but then in the message
allows the sender to specify a completely different set of sender and
recipient information that gets displayed in the mail client.


Yeah.  Almost like it is approximating the difference between what is on 
the outside of a postal envelope versus what is on the letterhead and 
opening of a piece of paper mail, which also permit such independence...


The essential problem with seeing these as 'problems' is confusing 
'common' with 'required'.  Common scenarios are fine, but so are the 
variants.  The variants often blow apart the simplifying assumption that 
one can incorrectly believe from the common scenarios.


d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

Re: why IPv6 isn't ready for prime time, SMTP edition

[John Levine]

>What if Google, Apple, Sony or some other household brand, sold a TV with 
>local mail capabilities, instead of pushing
>everyone to use their hosted services?

It would suck, because real users check their mail from their
desktops, their laptops, and their phones.  Your TV would not have the
sophisticated mail sorting, archiving, and searching of the large mail
systems.  And, of course, when its cheap SSD flaked, you'd lose all
your saved mail.

I swear, this whole conversation feels like I've fallen through a
wormhole into 1998.

Why IPv6 isn't ready for prime time :-)

[Tim Durack]

NANOG arguments on IPv6 SMTP spam filtering.

Deutsche Telecom discusses IPv4->IPv6 migration:

https://ripe67.ripe.net/presentations/131-ripe2-2.pdf

Facebook goes public with their IPv4->IPv6 migration:

http://www.internetsociety.org/deploy360/blog/2014/03/facebooks-extremely-impressive-internal-use-of-ipv6/

If you haven't started, you've got some work to do. Y2K/IPv6 consulting
gigs? Nice little earner!

-- 
Tim:>

Re: IPv6 isn't SMTP

[Clay Fiske]

On Mar 27, 2014, at 12:16 PM, Blake Hudson  wrote:

> It's entirely likely that a spammer would try to get a hold of a key due to 
> its value or that someone you've done business with would share keys with a 
> "business" partner . But ideally you'd authorize each sender with a unique 
> key (or some sort of pair/combination). So that 1) you can tell who the 
> spammer sourced the key from and 2) you can revoke the compromised key's 
> authorization to send you subsequent email messages.
> 
> There's probably some way to generate authorization such that each sender 
> gets a unique key or a generic base is in some way salted or combined with 
> information from the individual you're giving your authorization to such that 
> the result is both unique and identifiable.

(Not to single you out, but this is a good entry point.)

So somewhere between this and the “every user should have their own MTA” idea, 
something would need to be done to close the end user usability gap.

- “I just bought something from this boutique website, how do I (or my ISP) 
know how to let them email me my receipt?”
- “My friend gave his buddy my email address to send a resume for that job 
opening I have. How do I permit him to send me email?”
- “This .gov entity needs to email me about my (taxes|health care|car 
registration|…), how do I give them permission?”
- “My long lost high school friend found my email address somewhere (and isn’t 
using gmail, hotmail, yahoo, ….), how do I keep her from getting blocked?”

All of these end-user questions will have to be answered by any such technology 
which seeks to solve the spam problem using a manner such as you describe here. 
And if you’re going to say the solution is “in addition to my email address, in 
order to send me mail someone is going to have to know my (key|pass phrase|…)” 
then anything which currently collects your email address is also going to need 
to collect “that”. Therefore how do you control “that” from getting in the 
wrong hands in that list of emails someone is selling to spammers?

Am I misunderstanding what’s being proposed here? To me the ubiquity of email 
is its own undoing — it’s so convenient because you can email anybody, 
anywhere, from anywhere, but it’s so spammable because you can email anybody, 
anywhere, from anywhere.


-c

Re: IPv6 isn't SMTP

[Barry Shein]

On March 27, 2014 at 14:16 bl...@ispn.net (Blake Hudson) wrote:
 > 
 > Barry Shein wrote the following on 3/27/2014 2:06 PM:
 > >
 > >
 > > I suppose the obvious question is: What's to stop a spammer from
 > > putting a totally legitimate key into their spam?
 > >
 > It's entirely likely that a spammer would try to get a hold of a key due 
 > to its value or that someone you've done business with would share keys 
 > with a "business" partner . But ideally you'd authorize each sender with 
 > a unique key (or some sort of pair/combination). So that 1) you can tell 
 > who the spammer sourced the key from and 2) you can revoke the 
 > compromised key's authorization to send you subsequent email messages.
 > 
 > There's probably some way to generate authorization such that each 
 > sender gets a unique key or a generic base is in some way salted or 
 > combined with information from the individual you're giving your 
 > authorization to such that the result is both unique and identifiable.

Ok, this is a form of whitelisting with some authentication using
public key technology.

Sure. But is this really the problem you run into much? Someone
impersonating a sender you consider whitelisted?

I'm sure it happens.

But at a systems level I think most of us are talking about the much
more nefarious non-stop fire-hose of pure sewage.

Some white list, but for many that runs too great a risk of rejecting
serendipity, that great job offer from someone who was impressed by a
post you made on NANOG, etc.

So we get Challenge-Response etc as a workaround, which also has
problems.

Well, whatever, SPAM IS A BIG SUBJECT and there are a lot of
perspectives.

P.S. I always figured the problem you describe could be very trivially
solved by just agreeing to stick some word in the header like:

 X-PassCode: swordfish

It's not like anyone but the sender is likely to know that unless they
really are in your mail stream in which case you have other problems.

It would be nice if that were automated but it could be done manually.

I have certain Subject: phrases I use with people, some funny, so they
know it's almost certainly me.

-- 
-Barry Shein

The World  | b...@theworld.com   | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada
Software Tool & Die| Public Access Internet | SINCE 1989 *oo*

Re: Access Lists for Subscriber facing ports?

[Randy Bush]

two think that are simple, enforce bcp38 and ntp packet sizes

rndy

Re: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal)

[Randy Bush]

nanog is a separable game.  it is currently very confused between form
and substance, making committees for everything.  like the bcop thing.
two organizations, nanog and isoc, forming organizational structures to
create a document store.  the ops' doc store is ripe's because the ripe
wgs produced work and someone realized they needed a place to stash it.
so now nanog and isoc need to flag-plant.  the up-side is that it's a
great b-ark, keeps them from doing damage.

> And I would welcome discussion of how ARIN (and nanog) can be more
> like RIPE

i purposefully phrased it a bit differently, how can arin engage, get
real participation from, and serve its community, the operators.  i was
stealing examples from ripe.

but, for concrete action, how about a half day session at the next nanog
meeting on, for example, arin database services, whois and irr.  not to
try to reach hard conclusions or plans.  but to open a dialog to explore
what the community gets and wants from these services and how they are
provided.

or pick another key service.

randy

Re: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal)

[Cb B]

On Mar 27, 2014 3:03 PM, "John Curran"  wrote:
>
> And I would welcome discussion of how ARIN (and nanog) can be more like
RIPE - that is very much up to this community and its participation far
more than ARIN..
>
> /John
>

How about we fold ARIN into RIPE? Why not? I agree with all of Randy's
points. I am sure RIPE can easily scale up to take on ARIN services, with
fees being reduced for all involved due to economies of scale.

CB

> > On Mar 28, 2014, at 5:27 AM, Randy Bush  wrote:
> >
> > john,
> >
> > i think your attemt to move the discussion to the arin ppml list
> > exemplifies one core of the problem.  this is not about address policy,
> > but arin thinks of itelf as a regulator not a registry.
> >
> > contrast with the ripe community and the ncc, which is not nirvana but
> > is a hell of a lot better.  among other key differences, the ncc is
> > engaged with the community through technical and business working
> > groups.
> >
> > e.g. the database working group covers what you think of as whois and
> > the routing registry.  the wg developed the darned irr definition and
> > continues to evolve it.  consequence?  the irr is actively used in two
> > regions in the world, europe and japan (which likes anything ocd:-).
> >
> > the routing wg works with the ops to develop routing technology such as
> > route flap damping.  there is a reason that serious ops attend ripe
> > meetings.  yes, a whole lot of folk with enable are engaged.
> >
> > for years there has been a wg on the global layer nine issues.
> >
> > the dns wg deals with reverse delegation, root server ops, etc.  and
> > guess what, all the dns heavy techs and ops are engaged.
> >
> > there is a wg for discussing what services the ncc offers.  the recent
> > simplification and opening of services to legacy and PI holders happened
> > in the ncc services wg, it was about services not addressing policy.
> >
> > and this is aside from daniel's global measurement empire.  not sure it
> > is a registry's job to do this, but it is a serious contribution to the
> > internet.
> >
> > the ncc is engaged with its community on the subhects that actually
> > interest operators and affect our daily lives.
> >
> > there is nothing of interest at an arin meeting, a bunch of junior
> > wannabe regulators and vigilantes making an embarrassing mess.  i've
> > even taken to skipping nanog, if ras talks i can watch the recording.
> > all the cool kids will be in warsaw.  ops vote with our feet.
> >
> > randy
> >
>

Re: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal)

[Randy Bush]

hi john,

>> i think your attemt to move the discussion to the arin ppml list
>> exemplifies one core of the problem.
> I offered ppml out of respect to the nanog subscribers, that is all...

i will refrain from characterizing the ppml list.  needless to say, i do
not subscribe.

my point is that what arin does should be of interest to nanog
subscribers.  in theory, the ops are the arin community, the registry
serves operations.  if it is not of interest to ops, it is not serving
the community.

[ get out of s'pore yet?  drc got delayed a day with a missing part for
  his plane! ]

randy

Re: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal)

[John Curran]

And I would welcome discussion of how ARIN (and nanog) can be more like RIPE - 
that is very much up to this community and its participation far more than 
ARIN..

/John

> On Mar 28, 2014, at 5:27 AM, Randy Bush  wrote:
> 
> john,
> 
> i think your attemt to move the discussion to the arin ppml list
> exemplifies one core of the problem.  this is not about address policy,
> but arin thinks of itelf as a regulator not a registry.
> 
> contrast with the ripe community and the ncc, which is not nirvana but
> is a hell of a lot better.  among other key differences, the ncc is
> engaged with the community through technical and business working
> groups.
> 
> e.g. the database working group covers what you think of as whois and
> the routing registry.  the wg developed the darned irr definition and
> continues to evolve it.  consequence?  the irr is actively used in two
> regions in the world, europe and japan (which likes anything ocd:-).
> 
> the routing wg works with the ops to develop routing technology such as
> route flap damping.  there is a reason that serious ops attend ripe
> meetings.  yes, a whole lot of folk with enable are engaged.
> 
> for years there has been a wg on the global layer nine issues.
> 
> the dns wg deals with reverse delegation, root server ops, etc.  and
> guess what, all the dns heavy techs and ops are engaged.
> 
> there is a wg for discussing what services the ncc offers.  the recent
> simplification and opening of services to legacy and PI holders happened
> in the ncc services wg, it was about services not addressing policy.
> 
> and this is aside from daniel's global measurement empire.  not sure it
> is a registry's job to do this, but it is a serious contribution to the
> internet.
> 
> the ncc is engaged with its community on the subhects that actually
> interest operators and affect our daily lives.
> 
> there is nothing of interest at an arin meeting, a bunch of junior
> wannabe regulators and vigilantes making an embarrassing mess.  i've
> even taken to skipping nanog, if ras talks i can watch the recording.
> all the cool kids will be in warsaw.  ops vote with our feet.
> 
> randy
> 

Re: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal)

[John Curran]

> On Mar 28, 2014, at 5:27 AM, "Randy Bush"  wrote:
> 
> john,
> 
> i think your attemt to move the discussion to the arin ppml list
> exemplifies one core of the problem.

Randy -

I offered ppml out of respect to the nanog subscribers, that is all...

/John




> 
> 
> 
> and this is aside from daniel's global measurement empire.  not sure it
> is a registry's job to do this, but it is a serious contribution to the
> internet.
> 
> the ncc is engaged with its community on the subhects that actually
> interest operators and affect our daily lives.
> 
> there is nothing of interest at an arin meeting, a bunch of junior
> wannabe regulators and vigilantes making an embarrassing mess.  i've
> even taken to skipping nanog, if ras talks i can watch the recording.
> all the cool kids will be in warsaw.  ops vote with our feet.
> 
> ran

Re: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal)

[Randy Bush]

john,

i think your attemt to move the discussion to the arin ppml list
exemplifies one core of the problem.  this is not about address policy,
but arin thinks of itelf as a regulator not a registry.

contrast with the ripe community and the ncc, which is not nirvana but
is a hell of a lot better.  among other key differences, the ncc is
engaged with the community through technical and business working
groups.

e.g. the database working group covers what you think of as whois and
the routing registry.  the wg developed the darned irr definition and
continues to evolve it.  consequence?  the irr is actively used in two
regions in the world, europe and japan (which likes anything ocd:-).

the routing wg works with the ops to develop routing technology such as
route flap damping.  there is a reason that serious ops attend ripe
meetings.  yes, a whole lot of folk with enable are engaged.

for years there has been a wg on the global layer nine issues.

the dns wg deals with reverse delegation, root server ops, etc.  and
guess what, all the dns heavy techs and ops are engaged.

there is a wg for discussing what services the ncc offers.  the recent
simplification and opening of services to legacy and PI holders happened
in the ncc services wg, it was about services not addressing policy.

and this is aside from daniel's global measurement empire.  not sure it
is a registry's job to do this, but it is a serious contribution to the
internet.

the ncc is engaged with its community on the subhects that actually
interest operators and affect our daily lives.

there is nothing of interest at an arin meeting, a bunch of junior
wannabe regulators and vigilantes making an embarrassing mess.  i've
even taken to skipping nanog, if ras talks i can watch the recording.
all the cool kids will be in warsaw.  ops vote with our feet.

randy

Re: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability

[Matt Palmer]

On Wed, Mar 26, 2014 at 10:52:42AM -0600, kendrick eastes wrote:
> The Full-disclosure mailing list was recently... retired, I guess cisco
> thought NANOG was the next best place.

Nope, they've been sending these things here for as long as I can remember. 
I have NFI why -- probably hubris, thinking that everyone running a network
*must* have some Cisco somewhere.

- Matt

Re: IPv6 Security

[Karl Auer]

On Thu, 2014-03-27 at 05:34 -0700, Owen DeLong wrote:
> What do you think “Link Layer Address” (RFC 3315, Section 9.1 Type 3)
> is? From RFC-3315 Section 9.4, it seems pretty clear that is exactly what
> this is intended to be. True, it includes an additional 16 bits of media type,
> but I don’t see that as being a problem.

Though to be fair 3315 also says that the DUID should be treated as an
opaque blob, not parsed and bits extracted from it. From section 9:

   "Clients and servers MUST treat DUIDs as opaque values
and MUST only compare DUIDs for equality. Clients and
servers MUST NOT in any other way interpret DUIDs."

Regarding section 9.4, which you refer to: 3315 only uses MACs to
*construct* useful DUIDs, not as a means of communicating MACs to
clients or servers. Also, an operator cannot RELY on getting a MAC
address in a DUID.

DUID's *are* different and *do* require new ways of doing things. People
will work it out.

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882
Old fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A

Re: why IPv6 isn't ready for prime time, SMTP edition

[Brandon Ross]

On Thu, 27 Mar 2014, Owen DeLong wrote:


On Mar 27, 2014, at 11:15 AM, Barry Shein  wrote:

Please explain in detail where the fraud potential comes in.


Spammer uses his botnet of zombie machines to send email from each of them 
to his own domain using the user's legitimate email address as From:. 
Spammer says it was unsolicited and keeps the full $.10/email that victim 
users have deposited into this escrow thing.


Sounds a lot more profitable than regular spam.

--
Brandon Ross  Yahoo & AIM:  BrandonNRoss
+1-404-635-6667ICQ:  2269442
 Skype:  brandonross
Schedule a meeting:  http://www.doodle.com/bross

Re: Link Layer Filtering not supported on popular equipment?

[Mark Tinka]

On Thursday, March 27, 2014 06:42:12 PM Michael Loftis 
wrote:

> Similar issues with ACLs.  There are some options in
> Cisco (not certain if any of dell's products have this)
> that basically keep ports from talking to eachother, but
> allow them to talk to the upstream port (usually a
> router that can then enforce deeper ACLs and such).

Those would be private VLAN's in classic solutions, and 
split horizon bridge domains on carrier Ethernet platforms.

I find the latter simpler and more elegant, but limited to 
specific hardware.

Mark.


signature.asc
Description: This is a digitally signed message part.

Re: Remote Hands Spokane, WA?

[Jason Hellenthal]

I know a guy that lives out that way if you'd like me to bring him in.

-- 
 Jason Hellenthal
 Voice: 95.30.17.6/616
 JJH48-ARIN

> On Mar 27, 2014, at 15:11, "Aaron C. de Bruyn"  wrote:
> 
> Anyone available for remote hands (installing memory) in Spokane, WA on a
> Thursday during business hours?
> 
> -A


smime.p7s
Description: S/MIME cryptographic signature

Re: IPv6 isn't SMTP

[Blake Hudson]

Barry Shein wrote the following on 3/26/2014 11:24 PM:


Some will blanche at this but the entire spam problem basically arose
from the crap security in Windows systems, particularly prior to maybe
XP/SP2.

Not sure where all that leads us, however. Better security at those
major exploitation points, in a nutshell.

And if someone disagrees then please tell me how spammers as we know
them (and related miscreants) can operate without these few sources of
purloined resources.

Preferably without a big hand-wave like "oh they'll just find
something else!"

Maybe not!



You're largely right. Botnets are a big source of spam. As a mail server 
operator, they're the biggest source that I see. They're also easy to 
block through a number of means (The ISPs they're located on often block 
port 25, PBL (or similar), rDNS, and other behavior). It sounds like it 
will likely be a similar matter of blocking residential botnet 
participants on IPv6 due to the fact that residential ISPs will likely 
apply similar port 25 policy to IPv6 as they do to IPv4 and no rDNS.


However, as more attention is being payed to secure these end stations, 
spammers are looking at alternative avenues. In recent years, they've 
been harvesting user credentials through various means and then 
exploiting these compromised accounts to send email through otherwise 
legitimate servers. These are the spam messages that are hard to block. 
And these may be the areas where reputation based services will not be 
able to keep up in an IPv6 landscape. At least this concentrates the 
sources of spam (from my server's vantage point) and reduces the attack 
surface so that the problem is likely addressed more quickly and by 
someone with a higher level of knowledge than the average (unknowing) 
botnet participant.


Unfortunately, I can't keep Suzie teenager or Joe grandpa from giving 
his or her password out to a phisher. Fortunately, I can place 
reasonable limits on their accounts and the number of messages they're 
allowed to send or the rate at which they're allowed to send messages. 
If everyone else would just do the same we'd be a lot better off against 
this kind of attack.


--Blake

Re: why IPv6 isn't ready for prime time, SMTP edition

[Owen DeLong]

On Mar 27, 2014, at 11:15 AM, Barry Shein  wrote:

> 
> On March 26, 2014 at 22:25 o...@delong.com (Owen DeLong) wrote:
>> 
>> Actually, a variant on that that might be acceptable… Make e-postage a 
>> deposit-based thing. If the recipient has previously white-listed you or 
>> marks your particular message as “desired”, then you get your postage back. 
>> If not, then your postage is put into the recipients e-postage account to 
>> offset the cost of their emails.
>> 
>> Thoughts?
> 
> It's a fine idea but too complicated.
> 
> Look, the (paper) post office doesn't say "oh, you WANTED that mail,
> ok, then we'll return the cost of postage to the sender!"
> 
> Why? Because if they did that people would game the system, THEY'D
> SPAM!

How would they benefit from that?

SPAM — Pay, say $0.10/message.
Then Claim you wanted the SPAM, get your $0.10/message back for each SPAM you 
sent to yourself.
Or, claim you didn’t want the SPAM and get $0.05/message for each message you 
received while the
original provider keeps the other $0.05.

> And it would take way too much bookkeeping and fraud identification etc.

Please explain in detail where the fraud potential comes in.

By my interpretation, you’d have to somehow get more back than you deposited 
(not really possible) in order to profit from sending SPAM this way.

> Let's take a deep breath and re-examine the assumptions:
> 
> Full scale spammers send on the order of one billion msgs per day.
> 
> Which means if I gave your account 1M free msgs/day and could
> reasonably assure that you can't set up 1,000 such accts then you
> could not operate as a spammer.

Not sure how you enforce these user account requirements or how you avoid 
duplicative accounts.

> Who can't operate with 1M msgs/day?
> 
> Well, maybe Amazon or similar.
> 
> But as I said earlier MAYBE THEY SHOULD PAY ALSO!

I, for one, don’t want my Amazon prices increased by a pseudo-tax on the fact 
that they do a large volume of email communications with their customers. They 
have enough problems trying to get IPv6 deployed without adding this to their 
list of problems.

> We really need to get over the moral component of spam content (and
> senders' intentions) and see it for what it is: A free ride anyone
> would take if available.

I disagree. I see it as a form of theft of service that only immoral thieves 
would take if available.

> Ok, a million free per acct might be too high but whatever, we can all
> go into committee and do studies and determine what the right number
> should be.
> 
> I'd tend towards some sort of sliding scale myself, 100K/day free,
> 1M/day for $1, 10M/day for $100, 100M/day for $10K, etc. Something like
> that.
> 
> Why would it work?
> 
> Because that's how human society works.
> 
> People who are willing to pay their $10K/mo will demand something be
> done about freeloaders, enforcement has to be part of the cost
> overhead.

But who charges these fees and how do they enforce those charges against 
miscreants that are sending from stolen hosts, bots, fraudulent IP addresses, 
etc.?

> And it'd create an economy for hunting down miscreants.

So you’ve got a set of thieves who are stealing services to send vast volumes 
of email and you want to solve that problem by charging them more for those 
services that they are stealing (and, by the way, also charging some legitimate 
users as well).

My guess is that the spammers are going to keep stealing and the people now 
being taxed for something that used to be free are going to object.

> P.S. And in my vision accepting only email with valid e-postage would
> be voluntary though I suppose that might be "voluntary" at the
> provider level. For example someone like gmail at some point (of
> successful implementation of this scheme) might decide to just block
> invalid e-postage because hey your gmail acct is free! Let someone
> else sell you rules you prefer like controlling acceptance of invalid
> e-postage yourself.

Well, here we get a hint at how you envision this working. There are lots of 
details that need to be solved in the implementation of such a scheme and I 
think the devil is prevalent among them.

Owen

Re: IPv6 isn't SMTP

[Blake Hudson]

Barry Shein wrote the following on 3/27/2014 2:06 PM:



I suppose the obvious question is: What's to stop a spammer from
putting a totally legitimate key into their spam?

It's entirely likely that a spammer would try to get a hold of a key due 
to its value or that someone you've done business with would share keys 
with a "business" partner . But ideally you'd authorize each sender with 
a unique key (or some sort of pair/combination). So that 1) you can tell 
who the spammer sourced the key from and 2) you can revoke the 
compromised key's authorization to send you subsequent email messages.


There's probably some way to generate authorization such that each 
sender gets a unique key or a generic base is in some way salted or 
combined with information from the individual you're giving your 
authorization to such that the result is both unique and identifiable.


--Blake

Remote Hands Spokane, WA?

[Aaron C. de Bruyn]

Anyone available for remote hands (installing memory) in Spokane, WA on a
Thursday during business hours?

-A

Re: IPv6 isn't SMTP

[Barry Shein]

On March 27, 2014 at 08:51 bl...@ispn.net (Blake Hudson) wrote:
 > >
 > The primary issues I see with SMTP as a protocol related to the lack of 
 > authentication and authorization. Take, for instance, the fact that the 
 > SMTP protocol requires a mail from: and rcpt to: address (more or less 
 > for authentication and authorization purposes), but then in the message 
 > allows the sender to specify a completely different set of sender and 
 > recipient information that gets displayed in the mail client.

This is mostly a UI issue. The user interface could show anything,
custom certainly has been as you describe: Show the message From: and
make it tricky (for most people) to get the envelope info.

Well, it's not mandatory that an MTA transmit the envelope info into
the message headers and, almost worse, different MTAs seem to use
different header fields for this. For example in SpamAssassin you are
encouraged to set which field it should look at for the envelope
sender.

But that's not REALLY a problem with SMTP per se. Only in practice, if
that's a useful distinction.

I won't go point by point but I will say that SMTP has been extended
several times -- just throw another verb into the mix to extend it.

Which is a very useful observation. SMTP also can transmit which verbs
are supported. One can extend a new idea and it's immediately
interoperable.

I suppose the obvious question is: What's to stop a spammer from
putting a totally legitimate key into their spam?

You also need some sort of reputation layer. Or maybe that makes it
unworkable.

I remember at the 2006 MIT Spam Conference where Eric Allman and I
were keynotes we got into a bit of a tussle over exactly this during
his question period. It was...amusing!


-- 
-Barry Shein

The World  | b...@theworld.com   | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada
Software Tool & Die| Public Access Internet | SINCE 1989 *oo*

Education Committee Update

[Siegel, David]

Hi folks,

I would like to provide a brief update from the NANOG Education Committee.

We have filled several of the open committee positions but are still looking 
for more volunteers.
We need a Director of Instruction and several more "Members at Large."  Please 
contact Betty or
myself if you are interested in participating in the group.  My thanks go out 
to those who have already
volunteered, as follows:

Vice-Chair: Steve Gibbard
Program Director: Paul Emmons
Technical Director: Brandon Ross
Member at Large: Chris Spears

Of course, we continue to receive support from Betty Burke, Executive Director 
and Valerie Wittkop
for Project Management.

On the instruction front, we have two classes getting lined up for the Bellevue 
NANOG.  David Barak will be
joining us again to teach our 3rd Routing Fundamentals class and we are 
finalizing contracts now for an IPv6
course.  Registration will be open soon for both courses so stay tuned.

Dave Siegel
Chair, Ad-hoc Education Committee (NANOG)

Re: why IPv6 isn't ready for prime time, SMTP edition

[Laszlo Hanyecz]

Scott,

You are exactly right, in the current environment the things I'm suggesting 
seem unrealistic.  My point is that it doesn't have to work the way it does 
today, with the webmail providers, the mail originators and the spam warriors 
all scratching each others' backs.  There has been a LOT of work done to make 
webmail easy and everything else practically impossible, even if you do know 
how it works.  

What if Google, Apple, Sony or some other household brand, sold a TV with local 
mail capabilities, instead of pushing everyone to use their hosted services?  
If it doesn't work because we are blocking it on purpose, customers would 
demand that we make it work.  Since this isn't a well known option today, 
casual (non tech) users don't know that they should be demanding it.

As far as why someone would want an MTA, it doesn't take long to explain the 
benefits of having control over your own email instead of having a third party 
reading it all.  The problem is that instead users are told they can't have it. 
 MTAs are built into every user operating system and they would work just fine 
if the email community wasn't going out of their way to exclude them.  The lack 
of rDNS is just one of the many ways to identify and discriminate against end 
users who haven't bought their way into the club.

Spam is not a big problem for everyone.  It's at a different scale for 
individuals and for large sites with many users.

-Laszlo


On Mar 26, 2014, at 2:58 PM, Scott Buettner  wrote:

> This is totally ignoring a few facts.
> 
> A: That the overwhelming majority of users don't have the slightest idea what 
> an MTA is, why they would want one, or how to install/configure one. ISP/ESP 
> hosted email is prevalent only partially to do with technical reasons and a 
> lot to do with technical apathy on the part of the user base at large. Web 
> hosting is the same way. A dedicated mailbox appliance would be another cost 
> to the user that they would not understand why they need, and thus would not 
> want. In a hypothetical tech-utopia, where everyone was fluent in bash (or 
> powershell, take your pick), and read RFCs over breakfast instead of the 
> newspaper, this would be an excellent solution. Meanwhile, in reality, 
> technology frightens most people, and they are more than happy to pay someone 
> else to deal with it for them.
> 
> B: The relevant technical reason can be summarized as "good luck getting a 
> residential internet connection with a static IP"
> 
> (If your response includes the words "dynamic DNS" then please see point A)
> 
> (Also I'm just going to briefly touch the fact that this doesn't address spam 
> as a problem at all, and in fact would make that problem overwhelmingly 
> worse, as MTAs would be expected to accept mail from everywhere, and we 
> obviously can't trust end user devices or ISP CPE to be secure against 
> intrusion)
> 
> Scott Buettner
> Front Range Internet Inc
> NOC Engineer
> 
> On 3/26/2014 8:33 AM, Laszlo Hanyecz wrote:
>> Maybe you should focus on delivering email instead of refusing it.  Or just 
>> keep refusing it and trying to bill people for it, until you make yourself 
>> irrelevant.  The ISP based email made more sense when most end users - the 
>> people that we serve - didn't have persistent internet connections.  Today, 
>> most users are always connected, and can receive email directly to our own 
>> computers, without a middle man.  With IPv6 it's totally feasible since 
>> unique addressing is no longer a problem - there's no reason why every user 
>> can't have their own MTA.  The problem is that there are many people who are 
>> making money off of email - whether it's the sending of mail or the blocking 
>> of it - and so they're very interested in breaking direct email to get 'the 
>> users' to rely on them.  It should be entirely possible to build 'webmail' 
>> into home user CPEs or dedicated mailbox appliances, and let everyone deal 
>> with their own email delivery.  The idea of having to pay other people to 
>> host email for you is as obsolete as NAT-for-security, and this IPv6 SMTP 
>> thread is basically covering the same ground.  It boils down to: we have an 
>> old crappy system that works, and we don't want to change, because we've 
>> come to rely on the flaws of it and don't want them fixed.  In the email 
>> case, people have figured out how to make money doing it, so they certainly 
>> want to keep their control over it.
>> 
>> -Laszlo
>> 
>> 
>> On Mar 26, 2014, at 2:07 PM, Lamar Owen  wrote:
>> 
>>> On 03/25/2014 10:51 PM, Jimmy Hess wrote:
 [snip]
 
 I would suggest the formation of an "IPv6 SMTP Server operator's club,"
 with a system for enrolling certain IP address source ranges as  "Active
 mail servers", active IP addresses and SMTP domain names under the
 authority of a member.
 
>>> ...
>>> 
>>> As has been mentioned, this is old hat.
>>> 
>>> There is only one surefire way of doing away with

Re: why IPv6 isn't ready for prime time, SMTP edition

[Barry Shein]

On March 26, 2014 at 22:25 o...@delong.com (Owen DeLong) wrote:
 > 
 > Actually, a variant on that that might be acceptable? Make e-postage a 
 > deposit-based thing. If the recipient has previously white-listed you or 
 > marks your particular message as ?desired?, then you get your postage back. 
 > If not, then your postage is put into the recipients e-postage account to 
 > offset the cost of their emails.
 > 
 > Thoughts?

It's a fine idea but too complicated.

Look, the (paper) post office doesn't say "oh, you WANTED that mail,
ok, then we'll return the cost of postage to the sender!"

Why? Because if they did that people would game the system, THEY'D
SPAM!

And it would take way too much bookkeeping and fraud identification etc.

Let's take a deep breath and re-examine the assumptions:

Full scale spammers send on the order of one billion msgs per day.

Which means if I gave your account 1M free msgs/day and could
reasonably assure that you can't set up 1,000 such accts then you
could not operate as a spammer.

Who can't operate with 1M msgs/day?

Well, maybe Amazon or similar.

But as I said earlier MAYBE THEY SHOULD PAY ALSO!

We really need to get over the moral component of spam content (and
senders' intentions) and see it for what it is: A free ride anyone
would take if available.

Ok, a million free per acct might be too high but whatever, we can all
go into committee and do studies and determine what the right number
should be.

I'd tend towards some sort of sliding scale myself, 100K/day free,
1M/day for $1, 10M/day for $100, 100M/day for $10K, etc. Something like
that.

Why would it work?

Because that's how human society works.

People who are willing to pay their $10K/mo will demand something be
done about freeloaders, enforcement has to be part of the cost
overhead.

And it'd create an economy for hunting down miscreants.

There really is none now, outside of the higher profile DDoS or
phishing sort of activities.

I claim it wouldn't take much of this to shut down spammers.


P.S. And in my vision accepting only email with valid e-postage would
be voluntary though I suppose that might be "voluntary" at the
provider level. For example someone like gmail at some point (of
successful implementation of this scheme) might decide to just block
invalid e-postage because hey your gmail acct is free! Let someone
else sell you rules you prefer like controlling acceptance of invalid
e-postage yourself.


-- 
-Barry Shein

The World  | b...@theworld.com   | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada
Software Tool & Die| Public Access Internet | SINCE 1989 *oo*

Re: Switchport Counters - Take two

[Jim Glassford]

I have no experience with a Nexus 4001i, seems this could be counting up 
due to frames of no interest, wrong VLAN, Spanning tree, other.

Not by chance on a IBM BladeCenter?



The "input discard" counter on any internal interface (Ethernet1/1 - 
Ethernet1/14) may increment on Cisco Nexus 4001i switches, even when the 
connected blade is started into Unified Extensible Firmware Interface 
(UEFI) and not sending Operating System (OS) data.
This has been observed with QLogic Dual-Port 10 GB Converged Network 
Adapter (CFFh) for IBM BladeCenter, Option part number 42C1830, but may 
occur with other Network Interface Controllers (NICs).


Workaround:
This is a reporting issue. The 'input discards' are not counting actual 
packet loss.

Do not replace any hardware or update firmware.


On 3/27/2014 12:51 PM, rw...@ropeguru.com wrote:
Apologies to everyone for the original email with no subject. I am 
having some senior email moments today.


Anyway

So I certainly admit I am a basic networking guy and in the past have 
not had to get into the nitty gritty of port statistics.


I am trying to understand some statistics off a switch port in a Nexus 
4001i.


All TX and RX counters look normal except on the TX side, I am showing 
1107597 input discards. Last clearing of show counters is 1d8h ago.


I have it in my mind that this particular counter is dropping packets 
coming in from another port inside the switch that are to be 
transmitted out to the end server.


So lets say the interface I am looking at is port 2 on the switch. So 
server 1 sends a packet to port 1 on the switch. That packet then 
traverses to backplane, or inside the same ASIC, to port 2 on the 
switch. It is then dropped and not transmitted out to server 2.


Is the scenario I just presented correct? Not looking for the reason 
in this email, just that my logical understanding is correct.


Robert

Re: IPv6 Security [Was: Re: misunderstanding scale]

[Jack Bates]

On 3/27/2014 12:19 PM, Luke S. Crawford wrote:


This is a very common problem for dedicated hosting providers (and why 
I give my dedicated hosts a vlan and a routed subnet, wasting IPv4.)


Implement what some DSL access providers do. Unnumbered interfaces with 
/32 routing to the vlan. The last I checked, I think a J can even get 
the /32 route from radius when using autoconfig with radius auth. We did 
similar things with IPv6, as well. proxy-arp/proxy-nd to handle the 
cross talk.


IOS 12.1 7206 confirmed. No autoconf, but static subinterfaces for each 
vlan (q-in-q supported or atm), unnumbered to loopback. DHCPv4 and 
static routing works. IPv6 had issues, but could handle static /64 per 
subint.


ASR/J MX, autoconfig w/ radius backend, manual subint/unit, or 
combination. DHCPv4 confirmed, static host routes confirmed. IPv6 not 
confirmed. Radius static host route establishment not confirmed. Still 
testing.




Jack

Former 360/Ledcor employees from the NW

[D. Ryan Spott]

I am looking for some fiber in the PNW coastal area and for that field 
tech that knows where all the skeletons and vaults might be buried.


I know Ledcor installed it, 360-networks bought it and then Zayo now 
owns it but cannot find it on their maps.


ryan

Re: misunderstanding scale

[Barry Shein]

On March 26, 2014 at 22:17 o...@delong.com (Owen DeLong) wrote:
 > 
 > Then the spammers will grab /48s instead of /64s. Lather, rinse, repeat.

Hang on, do spammers "grab" address blocks?

Ok, I'm sure it happens, this is not an existence proof.

But is that really a significant characterization of their behavior?

That they go to an RIR or ISP and get an address block allocation?

I mean post-Ralsky (almost obscure historical spam reference.)

It seems like ALL the spam I see is purloined resources: botnets,
unauthorized use of (usually misconfigured) mail servers, web software
holes, free sites in general (such as google groups but also those
"community" free sites), etc.

I suppose this is the place where someone just says: "Yes, Barry, it
is" and considers the matter settled but it sure doesn't match my
experience.

We block a lot of /24s (like about 150,000 right now) and even a few
larger chunks but not because they're owned by spammers but because
they're repeatedly ABUSED by spammers.

But unfortunately they're just about always owned by people/companies
who believe they're legitimate but just can't seem to keep the
spammers from abusing them over and over. And the chance of ham from
them is so slight that one just blocks them wholesale.

Well, maybe for the purpose of this discussion it's the same thing,
how do you block blocks which are being abused or you want to block
for whatever reason.


-- 
-Barry Shein

The World  | b...@theworld.com   | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada
Software Tool & Die| Public Access Internet | SINCE 1989 *oo*

Re: IPv6 Security [Was: Re: misunderstanding scale]

[Luke S. Crawford]

It might make sense to just give everyone their own vlan and their own /64;  
that would, of course, bring its own problems and complexities (namely that 
I've gotta have the capability to deal with more customers than I can have 
native vlans -  not impossible to get around, but significant added complexity.)


I don’t see the point of that.



why not?  After carefully considering everything you have told me, this 
sounds like the way forward to do it the "IPv6 way"   -  privacy IPs 
would work fine, and I could filter every port such that only packets 
from that /64 were allowed out and only addresses to that /64 would be 
allowed in.Nobody would be able to spoof or listen in on their 
neighbor;  yeah, my router would have to send a lot of RAs, but routers 
that handle the amount of traffic my customers send are cheap.  I have a 
lot of customers, sure, but they are small.


Sure, it's going to cost me in routing complexity, but it looks like the 
only thing I can do that will actually solve my problems and use IPv6 
the way IPv6 is expecting to be used.


I'd then have to figure out how to make their ipv4 /32 work, but I can 
think of several possibilities that might work.  If nothing else, I 
could give them one interface for IPv6 and one for IPv4, and leave the 
IPv4 interface the current system.

Re: IPv6 Security [Was: Re: misunderstanding scale]

[Luke S. Crawford]

On 03/26/2014 11:14 PM, Owen DeLong wrote:

Why not just use private VLAN layer 2 controls for the privacy you describe?


The technology I know of is what cisco calls 'protected ports' -  My 
understanding is that those simply mean you can't pass traffic to or 
from other 'protected ports' -   I use that capability when, say, 
putting a bunch of IPMIs on a private network, it works great, as if one 
of the IPMI ports is trying to talk to another, something is very wrong 
and it gets blocked.


They are commonly used in the dedicated server hosting world to do what 
you are describing, but they have a big downside when being used on the 
public side;customer 1 can't talk to customer 2.Now, this isn't 
usually a big deal, except in one very common case;  what if one entity 
buys two hosts?  now those two hosts can't talk to oneanother.


This is a very common problem for dedicated hosting providers (and why I 
give my dedicated hosts a vlan and a routed subnet, wasting IPv4.)


For my virtuals, though, I have a much more clever "switch"  as it's 
just some software running in the Dom0, so at least in the IPv4 world, 
filtering just their /32 in and out is a much better solution.




Yes, you risk customer A spoofing customer B, but is that really a problem in 
your environment? Really? If so, one could argue you might want to consider 
getting a better class of customers.



You wouldn't feel uncomfortable if some other company could come in and 
not only spoof your IP, but receive the return traffic?   Keep in mind 
that they could do this in a way that is quite difficult to detect or 
trace, if they were clever about it.


I may trust my provider, to a certain extent, but I certainly don't 
trust everyone who gives my provider money.

Re:

[rw...@ropeguru.com]

It is actually a 4001i for an IBM Blade Chassis. Sorry for that.

So in this setup, port a would be a trunk with multiple vlans 
connection back to a 6509. port b would be a switch port in access 
mode that connects to an IBM blade in the chassis.


Not sure that this situation fits either of those scenarios.

Overall problem is that we are seeing performance issues between 
servers. These servers are all AIX based. We believe/know that we have 
some misconfigurations in the environment with jumbo frames and flow 
control. My curiosity about the discards is due to those 
misconfigurations. The port I mentioned in my original email has 
around 480 million output packes to the 1.1 million discards.


We do have IBM and Cisco support engaged, I am just trying to make 
sure I understand enough to be dangerous when I am working with them.


Robert

On Thu, 27 Mar 2014 12:55:46 -0400
 Lee  wrote:

On 3/27/14, rw...@ropeguru.com  wrote:
So I certainly admit I am a basic networking guy and in the past 
have not

had to get into the nitty gritty of port statistics.

I am trying to understand some statistics off a switch port in a 
Nexus

4001i.


Good luck.  I couldn't find anything for a nexus 4000, but did find
this for IOS:
In-Discard - The result of inbound valid frames that were discarded
because the frame did not need to be switched. This can be normal if 
a
hub is connected to a port and two devices on that hub exchange 
data.

The switch port still sees the data but does not have to switch it
(since the CAM table shows the MAC address of both devices 
associated

with the same port), and so it is discarded. This counter can also
increment on a port configured as a trunk if that trunk blocks for
some VLANs, or on a port that is the only member of a VLAN.

so if you've got something like
switch a: switchport trunk allowed vlan 1-5
switch b: switchport trunk allowed vlan 1-4

when switch a sends a frame on vlan 5, switch b counts it as an 
input discard.


Lee



All TX and RX counters look normal except on the TX side, I am
showing 1107597 input discards. Last clearing of show counters is 
1d8h ago.


I have it in my mind that this particular counter is dropping 
packets coming
in from another port inside the switch that are to be transmitted 
out to the

end server.

So lets say the interface I am looking at is port 2 on the switch. 
So server
1 sends a packet to port 1 on the switch. That packet then traverses 
to
backplane, or inside the same ASIC, to port 2 on the switch. It is 
then

dropped and not transmitted out to server 2.

Is the scenario I just presented correct? Not looking for the reason 
in this

email, just that my logical understanding is correct.

Robert


Sent from my Verizon Wireless 4G LTE smartphone

Re:

[Lee]

On 3/27/14, rw...@ropeguru.com  wrote:
> So I certainly admit I am a basic networking guy and in the past have not
> had to get into the nitty gritty of port statistics.
>
> I am trying to understand some statistics off a switch port in a Nexus
> 4001i.

Good luck.  I couldn't find anything for a nexus 4000, but did find
this for IOS:
In-Discard - The result of inbound valid frames that were discarded
because the frame did not need to be switched. This can be normal if a
hub is connected to a port and two devices on that hub exchange data.
The switch port still sees the data but does not have to switch it
(since the CAM table shows the MAC address of both devices associated
with the same port), and so it is discarded. This counter can also
increment on a port configured as a trunk if that trunk blocks for
some VLANs, or on a port that is the only member of a VLAN.

so if you've got something like
switch a: switchport trunk allowed vlan 1-5
switch b: switchport trunk allowed vlan 1-4

when switch a sends a frame on vlan 5, switch b counts it as an input discard.

Lee

>
> All TX and RX counters look normal except on the TX side, I am
> showing 1107597 input discards. Last clearing of show counters is 1d8h ago.
>
> I have it in my mind that this particular counter is dropping packets coming
> in from another port inside the switch that are to be transmitted out to the
> end server.
>
> So lets say the interface I am looking at is port 2 on the switch. So server
> 1 sends a packet to port 1 on the switch. That packet then traverses to
> backplane, or inside the same ASIC, to port 2 on the switch. It is then
> dropped and not transmitted out to server 2.
>
> Is the scenario I just presented correct? Not looking for the reason in this
> email, just that my logical understanding is correct.
>
> Robert
>
>
> Sent from my Verizon Wireless 4G LTE smartphone

Switchport Counters - Take two

[rw...@ropeguru.com]

Apologies to everyone for the original email with no subject. I am 
having some senior email moments today.


Anyway

So I certainly admit I am a basic networking guy and in the past have 
not had to get into the nitty gritty of port statistics.


I am trying to understand some statistics off a switch port in a Nexus 
4001i.


All TX and RX counters look normal except on the TX side, I am showing 
1107597 input discards. Last clearing of show counters is 1d8h ago.


I have it in my mind that this particular counter is dropping packets 
coming in from another port inside the switch that are to be 
transmitted out to the end server.


So lets say the interface I am looking at is port 2 on the switch. So 
server 1 sends a packet to port 1 on the switch. That packet then 
traverses to backplane, or inside the same ASIC, to port 2 on the 
switch. It is then dropped and not transmitted out to server 2.


Is the scenario I just presented correct? Not looking for the reason 
in this email, just that my logical understanding is correct.


Robert

Re: Link Layer Filtering not supported on popular equipment?

[Michael Loftis]

On Wed, Mar 26, 2014 at 9:08 AM, hasser css  wrote:
> Is there any common equipment that doesn't support this kind of filtering?
> I have no access to the switches where I work (I am just a CS agent at a
> smaller service provider), but my boss tells me that they do not support
> doing this... however, I do not believe this at all. I think that all the
> switches are all from Dell. Issues are happening as some customers
> accidentally have rogue DHCP servers running from their routers being
> connected improperly, and his only solution to this issue is to disable the
> switch port instead of simply preemptively filtering out this.
>
> Any insight? Regards.

The supported options vary within the PowerConnect product line.  So
it depends entirely on WHAT exact switch.  Some do support DHCP
snooping like that, some don't.  Even with it on it can create it's
own problems, on the 6248 f/ex this causes the DHCP replies from
trusted ports to always get copied to the CPU so it can inspect them
and create it's VLAN+MAC+IP bindings databases.  All untrusted port
DHCP traffic gets punted to CPU.  The gist is that this can open up a
potential DoS attack on the switch, or, even without that, the DHCP
traffic might be too high for the switch to manage.

Similar issues with ACLs.  There are some options in Cisco (not
certain if any of dell's products have this) that basically keep ports
from talking to eachother, but allow them to talk to the upstream port
(usually a router that can then enforce deeper ACLs and such).

All of these additional protection/security methods can have their
drawbacks for any particular environment, assuming the hardware even
supports them.

-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler

Re: IPv6 Security

[sthaug]

> > DHCPv6 as defined in RFC 3315 does not offer client MAC address at all
> > (thus making the job more difficult for a number of organizations).
> 
> Yes it does…
> 
> What do you think “Link Layer Address” (RFC 3315, Section 9.1 Type 3)
> is? From RFC-3315 Section 9.4, it seems pretty clear that is exactly what
> this is intended to be. True, it includes an additional 16 bits of
> > media type,

- I cannot a priori know which DUID type a particular client will use.
Of the three DUID types in RFC 3315 section 9.1, type 1 and 3 include
link layer address while type 2 does not.

- As has already been pointed out, the same physical hardware may use
different DUID types when booted with different operating systems.

- The language in RFC 3315 is pretty explicit in saying that a server
*must* treat the DUID as an opaque value - in other words, you are not
allowed to "inspect" it in any way to find the presumed MAC address
and take any action based on the MAC address.

> > All I've seen so far indicates that this was a deliberate choice by
> > the DHCPv6 designers, and in my opinion a very poor one. Fortunately
> > we now have RFC 6939 (DHCPv6 Client Link-Layer Address Option), and
> > we're waiting for vendors to implement this. That solves one half of
> > the problem.
> 
> Yes and no.
> 
> At the time RFC3315 was written, network cards changed independent of
> motherboards on a regular basis and this fact was a source of great
> consternation for DHCPv4 operators. Over time, that changed AFTER
> RFC3315 was written, but if you read section 9.4, it seems pretty clear that
> this change was anticipated by the authors and that DUID-LL was intended
> for the situation we have today.

I think understand the well-meant intentions of the RFC 3315 authors.
However, my claim is that the actual end result for IPv6 leaves us in
a *worse* situation than for IPv4. And one which, among others, makes
it very difficult to correlate IPv4 and IPv6 leases (something which
I have no need for today, but which I could easily see a need for in
the future).

Steinar Haug, Nethelp consulting, sth...@nethelp.no

Re: WISP or other options

[James Harrison]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 27/03/14 14:04, Dustin Jurman wrote:
> There are plenty of  Microwave products that produce that type of
> bandwidth and more, LOS and NLOS.  I do not know if there is a
> WISPA counterpart in Scotland but you may want to reach out to
> WISPA to see if they know of an organization.  You can also reach
> out to Cambium to see whom their partners are in the area.

Indeed - there's fairly local transit capacity (though it is via a BT
exchange, so good luck actually getting a reasonable price off BTWC
for a temporary line) and doing LOS on some temporary towers should be
within the capabilities of some creative engineers. WISPA might be a
good starting point, INCA can certainly put you in touch with the
local crowd to advise.

Either way it'd certainly work out a heck of a lot cheaper than sat.
You can do 3G (DC-HSDPA) in that area on at least one MNO but probably
want a decent directional antenna with some gain on it. That'd
probably work out cheapest, but will be bandwidth limited and you'd be
looking at a fair few devices bonded to get that much bandwidth.

- -- 
Cheers,
James
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTNEvqAAoJENTyYHL8dmp9StIP/RnilFJ1SzfEqsQ5dkxMO+Hg
jc7b4q41h7sNiWoWjRPbjc/nRsG0JNHIK/JicfuOKVzlrCIBdhO30B+EnR2DhZ+i
roc09WwbJckwoGwTZjvXESm1qJE1bZTynr7nrrc7WFXak6HDN3MZqhHlkElShYAg
i7Al5m5LjUFXKr+xorOam84w/DcmgFCi5SzAQOu5fTvQxbJ1gmiwb+n7q5V6xzRH
/B+bRFBwaqW6mtTQ2Wh9lxxXaMoIRHWfo/AlI21Z8FyKANArypqBC3YNw0BSkeBP
kN3dRy6AlbmhFQ3XaiOrYiHbx/vp4WV3VVe6S8/Suey2eKASmyglB3nfeCYvokOk
kvMs4phfE8lTAntMm0HKykHtZHtPbUdwTOag4TyYCjlBtLZahBDqF9Q6TFwuhhxL
e1Vi86PEpPgMGAGlim81DCHu9/BwWsvnp2R98/hAW5bMTanm6sBcAera0EYrAtKr
MXYN5WOmAZzVxW/x1nbtxYBM8iNG2fY/w0lGDH+2Z7DgJxP/WQOVUhU3UCJcQYgi
jkx9BSjBJJtyR6F/WKxKbDhIaTfZ58Y7qNqXpg27z1KuCxkz9HdpjYH2kuMO5icx
Hq29kD4cJm5APCcBjyP8mlIyHG2GZqeNmJLaSfmCWYwhuf/XOKQQbgtOdfMLsoyS
z3OJ0iuivtdirXz7RAoR
=eyO1
-END PGP SIGNATURE-

RE: Switchport Counters

[rw...@ropeguru.com]

Sent from my Verizon Wireless 4G LTE smartphone

 Original message 
From: rw...@ropeguru.com 
Date:03/27/2014  11:52 AM  (GMT-05:00) 
To: nanog@nanog.org 
Subject:  

[no subject]

[rw...@ropeguru.com]

So I certainly admit I am a basic networking guy and in the past have not had 
to get into the nitty gritty of port statistics.

I am trying to understand some statistics off a switch port in a Nexus 4001i.

All TX and RX counters look normal except on the TX side, I am showing 1107597 
input discards. Last clearing of show counters is 1d8h ago.

I have it in my mind that this particular counter is dropping packets coming in 
from another port inside the switch that are to be transmitted out to the end 
server.

So lets say the interface I am looking at is port 2 on the switch. So server 1 
sends a packet to port 1 on the switch. That packet then traverses to 
backplane, or inside the same ASIC, to port 2 on the switch. It is then dropped 
and not transmitted out to server 2.

Is the scenario I just presented correct? Not looking for the reason in this 
email, just that my logical understanding is correct.

Robert


Sent from my Verizon Wireless 4G LTE smartphone

Re: WKBIs, was why IPv6 isn't ready for prime time, SMTP edition

[John Levine]

>Actually, a variant on that that might be acceptable� Make e-postage a 
>deposit-based thing. If the recipient has
>previously white-listed you or marks your particular message as �desired�, 
>then you get your postage back. If not,
>then your postage is put into the recipients e-postage account to offset the 
>cost of their emails.
>
>Thoughts?

You could have bought the patent on this WKBI on eBay last year:

http://www.ebay.com/itm/251279133681

When I was running the ASRG, I set up a wiki where we could keep a
taxonomy of anti-spam techniques, so we could save time and just point
people at it when they reinvent them.  It's still there, contributions
of anything we've missed are still welcome:

http://wiki.asrg.sp.am/wiki/Attention_bonds

R's,
John

PS: Well Known Bad Idea

Re: [mailop] IPv6 DNSBL

[Jim Popovitch]

On Thu, Mar 27, 2014 at 9:21 AM, David Hofstee  wrote:
> There must be a good reason for people to get of their asses and start 
> implementing things like DMARC. All the banks (!$%^) I talk to do not have 
> any reason to implement it swiftly (they turn on p=none and then all progress 
> stops). Frustrating that they are too lazy to implement a few DNS records.
>
> It only needs firm backing by 3+ large companies like Hotmail. Give everyone 
> on IPv6 without DMARC a large spamscore (and publish that beforehand ;-) ). 
> Give me ammunition and all corporates will move.
>

Please no.  DMARC is great for 1:1 direct email  (from:me, to:you).
Anything other than p=none fails miserably once the scope is expanded.
 Let me give you examples of things that would fail miserably under
your suggestion above:

1)  This list

2)  The recent, heavily forwarded and reflected, Cisco PSIRT notices.


NANOG is not the place to debate this, nor is it the place to advocate
self inflicted harm.

-Jim P.

Re: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability

[cbr]

For anyone who was subscribed to the old full-disclosure list ... Fydor of nmap 
has brought it back to life.


Infolink @ http://insecure.org/news/fulldisclosure/
Subscribe @ http://nmap.org/mailman/listinfo/fulldisclosure


On Mar 26, 2014, at 10:52 AM, kendrick eastes  wrote:

> The Full-disclosure mailing list was recently... retired, I guess cisco
> thought NANOG was the next best place.
> 
> 
> On Wed, Mar 26, 2014 at 10:45 AM, rw...@ropeguru.com 
> wrote:
> 
>> 
>> Is this normal for the list to diretly get Cisco security advisories or
>> something new. First time I have seen these.
>> 
>> Robert
>> 
>> 
>> On Wed, 26 Mar 2014 12:10:00 -0400
>> Cisco Systems Product Security Incident Response Team 
>> wrote:
>> 
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>> 
>>> Cisco IOS Software SSL VPN Denial of Service Vulnerability
>>> 
>>> Advisory ID: cisco-sa-20140326-ios-sslvpn
>>> 
>>> Revision 1.0
>>> 
>>> For Public Release 2014 March 26 16:00  UTC (GMT)
>>> 
>>> Summary
>>> ===
>>> 
>>> A vulnerability in the Secure Sockets Layer (SSL) VPN subsystem of Cisco
>>> IOS Software could allow an unauthenticated, remote attacker to cause a
>>> denial of service (DoS) condition.
>>> 
>>> The vulnerability is due to a failure to process certain types of HTTP
>>> requests. To exploit the vulnerability, an attacker could submit crafted
>>> requests designed to consume memory to an affected device. An exploit could
>>> allow the attacker to consume and fragment memory on the affected device.
>>> This may cause reduced performance, a failure of certain processes, or a
>>> restart of the affected device.
>>> 
>>> Cisco has released free software updates that address this vulnerability.
>>> There are no workarounds to mitigate this vulnerability.
>>> 
>>> This advisory is available at the following link:
>>> http://tools.cisco.com/security/center/content/
>>> CiscoSecurityAdvisory/cisco-sa-20140326-ios-sslvpn
>>> 
>>> Note: The March 26, 2014, Cisco IOS Software Security Advisory bundled
>>> publication includes six Cisco Security Advisories. All advisories address
>>> vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security
>>> Advisory lists the Cisco IOS Software releases that correct the
>>> vulnerability or vulnerabilities detailed in the advisory as well as the
>>> Cisco IOS Software releases that correct all Cisco IOS Software
>>> vulnerabilities in the March 2014 bundled publication.
>>> 
>>> Individual publication links are in Cisco Event Response: Semiannual
>>> Cisco IOS Software Security Advisory Bundled Publication at the following
>>> link:
>>> 
>>> http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar14.html
>>> -BEGIN PGP SIGNATURE-
>>> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
>>> Comment: GPGTools - http://gpgtools.org
>>> 
>>> iQIcBAEBAgAGBQJTMeUtAAoJEIpI1I6i1Mx3BJ4P/Aytcbvaue49DkNDq0G+3C8+
>>> mv2W8/1HeqSvrmbc8QUJrelPA1kfYXGSf+7VX9lpwTdKKPrMPpkso1WXA7tK2t5i
>>> uiaqy8+KON/V3uFTjLhSBxZsMmSYws/uO8rV9oY7NLGfv2cwGztEbrKwz9g5Hsfc
>>> X3TlEgPaX73a/xb92eP//+e31ZNCPw6NRKmUfi6v7YG38WNghT7lqtI7GVlHiAkd
>>> atAqZ8NOyn7V+lHNjdOpAzFplo6R+GZCBfAFkEYuEU3dAAccMQbkaq6XgZAigycn
>>> dko3EWzfa+I/4RHDrRIa/XAY6Ogrnp/jmaTm4sGF2aqQOASH7X/oDU4X6KnD6ixo
>>> RicU1XeEsxgh5/FOf0wWo53BTcf/1nx34LkazZ6k6+jh8193IRWGb9J90E7S+/M8
>>> 2jbB8kwxuroH1qQ73jqguiuTC0eemPn2k5MS01ZAfcIEJPcA4OyTkuA/3tiISeYQ
>>> 0GesrJ3m7WOovFNSIq8v4WaTMcvZO9vHLZ/6BMcd4a+1uPnzPeR9rfI8JA2VA8Wd
>>> EAjbKdWA/kPxbVop2ajRjYTl7uMN6/g9SFP/eBjWpAFLnUfE6n1b24cn9v26OQpB
>>> ZxuMKA6eaeoT88KlouxudQcAgtpZZFzp4/ghWCy8q82WhHg4uDqw3R243rRxaBa7
>>> RF3x0wYuErbbC7N9m1UH
>>> =1Ixo
>>> -END PGP SIGNATURE-
>>> 
>>> 
>> 
>> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: why IPv6 isn't ready for prime time, SMTP edition

[John R. Levine]

Ergo, ad hominem. Please quit doing that.
As a side note I happen to run my own mail server without spam filters
-- it works for me. I might not be the norm, but then again, is there
really a norm? (A norm that transcends SMTP RFC reach, that is --


I know a lot of people who run a lot of mail systems, and let's just say 
you're so far out in the long tail we need a telescope to see you.


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

Re: IPv6 isn't SMTP

[Lamar Owen]

On 03/26/2014 08:12 PM, Jimmy Hess wrote:

As far as i'm concerned  if you can force the spammer to use their own
IP range, that they can setup RDNS for,  then you have practically  won,
  for all intents and purposes,   as it makes blacklisting feasible, once
again!

Spammers can jump through these hoops ---  but spammers aren't going to
effectively scale up their spamming operation by using IP address ranges
they can setup RDNS on.

Tell that to the 100,000+ e-mails I blocked last week (and the several 
hundred that got through before I was able to get all the blocks entered 
into my ingress ACLs) from proper rDNS addresses where the addresses 
were hopping all over a /24, a /22, three /21's, four /20's, and six 
/19s in widely separated blocks.  Every single address in those blocks 
eventually attempted to send e-mail, and every address had proper rDNS 
for the pseudorandom domain names, mostly in the .in TLD, but some 
others, too (the blocks were all over, with some registed through ARIN, 
some through RIPE, some through AfriNIC, and some through APNIC, with 
hosters in Europe, North and South America, Asia, and Africa.)  Note 
that these passed full FCrDNS verification in postfix.  They all had 
very similar characteristics, including an embedded image payload/ad and 
a couple of hundred kB of anti-Bayesian text, including the full text of 
Zilog's Z80 manual at one point.


Of course, the other tens of thousands per day that get blocked for not 
having rDNS from residential bots make the case for leaving rDNS (and 
the FCrDNS variant) turned on, but it is not a cure-all.

Re: Link Layer Filtering not supported on popular equipment?

[Dobbins, Roland]

On Mar 26, 2014, at 11:08 PM, hasser css  wrote:

> Any insight? 

I don't know about Dell switches, but Cisco switches have DHCP Snooping, IP 
Source Guard, PACLs, VACLs, and so forth at layer-2.

---
Roland Dobbins  // 

  Luck is the residue of opportunity and design.

   -- John Milton

Re: IPv6 isn't SMTP

[John R. Levine]

mailbox@[IPv6:2001:12:34:56::78:ab:cd]


You aren't allowed to use :: to abbreviate one zero hexadectet according
to RFC 5952.

http://www.rfc-editor.org/errata_search.php?eid=2467


Oh, look at that.  I wonder how many people realized that it made an 
incompatible change to RFC 4291 four years ago.  I certainly didn't.  I 
wonder what problem they thought they were solving.


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

Re: IPv6 isn't SMTP

[Enno Rey]

Hi,

On Thu, Mar 27, 2014 at 01:52:27PM +, Tony Finch wrote:
> John Levine  wrote:
> >
> > There are also some odd things in the spec.  For example, according to
> > RFC 5321 this is not a syntactically valid e-mail address:
> >
> > mailbox@[IPv6:2001:12:34:56::78:ab:cd]
> 
> You aren't allowed to use :: to abbreviate one zero hexadectet according
> to RFC 5952.

well, RFC 5952 _recommends_ against using that. Still, it's perfectly valid as 
of RFC 4291 and the approach can be found in quite large vendors' 
implementations, see http://labs.apnic.net/blabs/?p=309.

RFC 5952 explicitly states:
"all implementations must accept and be able to
   handle any legitimate RFC 4291 format."


best

Enno





> 
> http://www.rfc-editor.org/errata_search.php?eid=2467
> 
> Tony.
> -- 
> f.anthony.n.finchhttp://dotat.at/
> Malin: East 5 or 6. Moderate or rough, occasionally very rough in northwest.
> Showers. Good, occasionally moderate.
> 

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

===
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
===

RE: WISP or other options

[Dustin Jurman]

There are plenty of  Microwave products that produce that type of bandwidth and 
more, LOS and NLOS.  I do not know if there is a WISPA counterpart in Scotland 
but you may want to reach out to WISPA to see if they know of an organization.  
You can also reach out to Cambium to see whom their partners are in the area.  

Dustin Jurman


-Original Message-
From: Warren Bailey [mailto:wbai...@satelliteintelligencegroup.com] 
Sent: Wednesday, March 26, 2014 11:35 PM
To: Nick; nanog@nanog.org
Subject: Re: WISP or other options

20-60mbps is a tall order.

I¹d say cellular.. Maybe you can pair together a couple of 4g cradle points and 
do load balancing on them?

You are screwed for LOS microwave, 60mbps on a microwave hope requires real 
life engineering to function correctly. Frequency coordination, towers, AGL 
requirements. If you¹re looking for satellite, I can tell you for certain that 
a 60mbps circuit for a month would exceed 140k a month in your neck of the 
woods. That¹s just to start off, it can get higher as the link budget dictates.

Is there any reason you need THAT much? Have you thought about using 
compression stuff at all? Are these people paying for it?

On 3/26/14, 8:30 PM, "Nick"  wrote:

>Hey,
>
>I have a weird off the wall question for a NA group.
>
>Does any have contacts in Edinburgh Scotland who can provide WISP 
>service at the Hopetoun House and Dundas Castle. I would like to have 
>20-60mpbs to for 2 days of services.
>
>Our company's event planner claims there are no good ISP options in the 
>area and wants us to go with satellite internet which is pricy and has 
>high latency. Its worth noting both locations have ~7mpbs DLS.
>
>I'm also open to other options.
>
>
>Thanks,
>
>Nick Poulakos
>

Re: IPv6 isn't SMTP

[Tony Finch]

Owen DeLong  wrote:
>
> Two errors, actually… As an RFC-821 address, it should be user@[IP]:port
> in both cases (user@[192.0.2.1]:25 and user@[2001:db8::1]:25).

You have never been able to specify a port number in an email address.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Lundy, Fastnet: East or northeast 4 or 5, occasionally 6 later. Moderate
becoming rough in south. Thundery showers. Good, occasionally poor.

Re: WISP or other options

[Alex Howells]

On 27 March 2014 05:09, Warren Bailey <
wbai...@satelliteintelligencegroup.com> wrote:

>  I think the real problem here is the event is for 2 days and he requires
> a metric shxt ton of data (for wireless anyways..). Sure you could get all
> kinds of COOL solutions together, but do you think the (UK Version) LEC is
> going to run DSL/fiber/blah for a two day event? And who bears that cost
> burden?
>

Yes. Absolutely. Getting a phone line or multiple installed for 2 days is
*completely* feasible, and depending on the length to the cabinet/exchange,
the speeds he wants are also not too difficult (~20Mbps) through bonding.

Both of the locations he has identified probably already have a significant
number of copper pairs into the building. There are more than likely to be
enough spare although the install process could be complicated if that is
not the case.

Typically speaking a line install costs from BT Openreach costs around
£50+VAT, but you'd pay £145+VAT to get an expedited install appointment. In
*theory* (never tried this myself) they should be able to install multiple
lines within the same appointment, so four lines might run you £345+VAT or
thereabouts although worst case you could be looking at £195+VAT per line.

I believe it's possible to just cancel them immediately after the event,
and that it's possible to avoid a 12 month minimum term, so you'd be
looking at fairly minimal rental costs (£12+VAT per line, or thereabouts)
to cover their rental for the 30 days covering your event.

I am not trivialising the use of AirFiber in the slightest, however, if
that's what it takes to get him the required bandwidth it's also not out of
the realm of possibility for someone (i.e. doing it through MaxWiFi) to set
up, for the required amount of money. I specifically stated it would be
more complex than a DSL line.

I think the OP was looking for solutions, not pages of text about how
difficult or impossible his situation actually is ;-)

Re: WISP or other options

[Alex Howells]

I think the AF5 should be legal over here, at least, the lower bands are
license free up to 1W transmit power.

Not used the AF5 at all yet, it's quite new, and the only AF24 experience I
have is only ~1000m worth of distance so comparatively easy to make work.

Either way you latched onto the point, which is "Where there's a will,
there's a way". In a lot of ways the UK is significantly more
forward-thinking in terms of what can be done with DSL lines, the US LECs
really aren't very imaginative. Who ever thought I'd be praising BT.


On 27 March 2014 10:10, William Waites  wrote:

> On Thu, Mar 27, 2014 at 05:09:05AM +, Warren Bailey wrote:
> > It's not 802.11 and it doesn't act that way.
>
> Actually most of the installations I've seen -- and my day job is
> working with community networks around Scotland that have built all
> manner of strange things -- the problems most often have nothing at
> all to do with the physical layer. More often they're related to doing
> things with spanning tree that we all learned in networking long ago
> to not do, or running many layers of NAT because IP routing is not
> understood. Things like that.
>
> The only common RF problem is leaving the channel selection on
> "auto". Which invariably means one radio, like an access point with a
> sector antenna, can't hear the point to point link coming in to the
> dish behind it and picks the wrong channel.
>
> Again, yes, you're right, you have to understand how this stuff works
> and think a little bit when you build, but your messages saying "It's
> really really hard" are coming across a little like FUD.
>
> > A pair of Air Fiber is like 3k USD, and at 24ghz you had better know
>
> The AF24 are also illegal here. Or rather the lower channel belongs to
> the police, and the upper channel is limited to a very low output
> power. We have a pair of these, with a special non-operational license
> from Ofcom to put them through their paces. They do work, though they
> are a pain to align and subject to rain fade. They are on the West
> coast which is very rainy. Right now we're using them to measure rain
> intensity rather than to carry real traffic (which we can't do with a
> non-op license anyways).
>
> -w
>
>
>

Re: WISP or other options

[Alex Howells]

Pay someone to worry about all this stuff, MaxWiFi has a good reputation in
the UK at least.

Stuff like the Ubiquiti Networks AirFiber can be good for getting from A-B
over "relatively short" distances if you've identified another place which
has really good connectivity which you can use, and if good connectivity is
truly critical to the events. Obviously this involves masts, may involve
permitting, and is a bit more complex than just a DSL line.

It's usually possible to bond multiple DSL connections, and it's not
impossible to get phone lines and DSL installed for short events either,
although it does depend on the venue being willing to accommodate you.

According to SamKnows the South Queensferry exchange (Dundas Castle) is
supposed to have gotten BT FTTC capability from 1st March and some LLU (O2,
TalkTalk, Sky) has happened, so again, talk to someone who specialises in
this stuff and they'll be able to navigate "What is the least fucked up way
to solve this for the event?".

HTH,
 -Alex

Looking for 2M service in CA

[Edison Smith-Stubbs]

Hi all,

Apologies if this is the incorrect forum for this request, first time
posting to the group!

I work for an ISP in Australia and we have a requirement to deliver a
service to a client site in CA. I'm not familiar with the American market
but I'd be interested in chatting with providers who can deliver 2M tails
between the following locations:

A End: Washington Avenue, San Leandro CA
B End: Equinix San Jose *OR *Coresite San Jose.

Response off list to esmithstu...@gmail.com would be appreciated.

Thanks in advance!

Ed

Re: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability

[kendrick eastes]

The Full-disclosure mailing list was recently... retired, I guess cisco
thought NANOG was the next best place.


On Wed, Mar 26, 2014 at 10:45 AM, rw...@ropeguru.com wrote:

>
> Is this normal for the list to diretly get Cisco security advisories or
> something new. First time I have seen these.
>
> Robert
>
>
> On Wed, 26 Mar 2014 12:10:00 -0400
>  Cisco Systems Product Security Incident Response Team 
> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Cisco IOS Software SSL VPN Denial of Service Vulnerability
>>
>> Advisory ID: cisco-sa-20140326-ios-sslvpn
>>
>> Revision 1.0
>>
>> For Public Release 2014 March 26 16:00  UTC (GMT)
>>
>> Summary
>> ===
>>
>> A vulnerability in the Secure Sockets Layer (SSL) VPN subsystem of Cisco
>> IOS Software could allow an unauthenticated, remote attacker to cause a
>> denial of service (DoS) condition.
>>
>> The vulnerability is due to a failure to process certain types of HTTP
>> requests. To exploit the vulnerability, an attacker could submit crafted
>> requests designed to consume memory to an affected device. An exploit could
>> allow the attacker to consume and fragment memory on the affected device.
>> This may cause reduced performance, a failure of certain processes, or a
>> restart of the affected device.
>>
>> Cisco has released free software updates that address this vulnerability.
>> There are no workarounds to mitigate this vulnerability.
>>
>> This advisory is available at the following link:
>> http://tools.cisco.com/security/center/content/
>> CiscoSecurityAdvisory/cisco-sa-20140326-ios-sslvpn
>>
>> Note: The March 26, 2014, Cisco IOS Software Security Advisory bundled
>> publication includes six Cisco Security Advisories. All advisories address
>> vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security
>> Advisory lists the Cisco IOS Software releases that correct the
>> vulnerability or vulnerabilities detailed in the advisory as well as the
>> Cisco IOS Software releases that correct all Cisco IOS Software
>> vulnerabilities in the March 2014 bundled publication.
>>
>> Individual publication links are in Cisco Event Response: Semiannual
>> Cisco IOS Software Security Advisory Bundled Publication at the following
>> link:
>>
>> http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar14.html
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
>> Comment: GPGTools - http://gpgtools.org
>>
>> iQIcBAEBAgAGBQJTMeUtAAoJEIpI1I6i1Mx3BJ4P/Aytcbvaue49DkNDq0G+3C8+
>> mv2W8/1HeqSvrmbc8QUJrelPA1kfYXGSf+7VX9lpwTdKKPrMPpkso1WXA7tK2t5i
>> uiaqy8+KON/V3uFTjLhSBxZsMmSYws/uO8rV9oY7NLGfv2cwGztEbrKwz9g5Hsfc
>> X3TlEgPaX73a/xb92eP//+e31ZNCPw6NRKmUfi6v7YG38WNghT7lqtI7GVlHiAkd
>> atAqZ8NOyn7V+lHNjdOpAzFplo6R+GZCBfAFkEYuEU3dAAccMQbkaq6XgZAigycn
>> dko3EWzfa+I/4RHDrRIa/XAY6Ogrnp/jmaTm4sGF2aqQOASH7X/oDU4X6KnD6ixo
>> RicU1XeEsxgh5/FOf0wWo53BTcf/1nx34LkazZ6k6+jh8193IRWGb9J90E7S+/M8
>> 2jbB8kwxuroH1qQ73jqguiuTC0eemPn2k5MS01ZAfcIEJPcA4OyTkuA/3tiISeYQ
>> 0GesrJ3m7WOovFNSIq8v4WaTMcvZO9vHLZ/6BMcd4a+1uPnzPeR9rfI8JA2VA8Wd
>> EAjbKdWA/kPxbVop2ajRjYTl7uMN6/g9SFP/eBjWpAFLnUfE6n1b24cn9v26OQpB
>> ZxuMKA6eaeoT88KlouxudQcAgtpZZFzp4/ghWCy8q82WhHg4uDqw3R243rRxaBa7
>> RF3x0wYuErbbC7N9m1UH
>> =1Ixo
>> -END PGP SIGNATURE-
>>
>>
>
>

Link Layer Filtering not supported on popular equipment?

[hasser css]

Is there any common equipment that doesn't support this kind of filtering?
I have no access to the switches where I work (I am just a CS agent at a
smaller service provider), but my boss tells me that they do not support
doing this... however, I do not believe this at all. I think that all the
switches are all from Dell. Issues are happening as some customers
accidentally have rogue DHCP servers running from their routers being
connected improperly, and his only solution to this issue is to disable the
switch port instead of simply preemptively filtering out this.

Any insight? Regards.

Re: why IPv6 isn't ready for prime time, SMTP edition

[Scott Buettner]

This is totally ignoring a few facts.

A: That the overwhelming majority of users don't have the slightest idea 
what an MTA is, why they would want one, or how to install/configure 
one. ISP/ESP hosted email is prevalent only partially to do with 
technical reasons and a lot to do with technical apathy on the part of 
the user base at large. Web hosting is the same way. A dedicated mailbox 
appliance would be another cost to the user that they would not 
understand why they need, and thus would not want. In a hypothetical 
tech-utopia, where everyone was fluent in bash (or powershell, take your 
pick), and read RFCs over breakfast instead of the newspaper, this would 
be an excellent solution. Meanwhile, in reality, technology frightens 
most people, and they are more than happy to pay someone else to deal 
with it for them.


B: The relevant technical reason can be summarized as "good luck getting 
a residential internet connection with a static IP"


(If your response includes the words "dynamic DNS" then please see point A)

(Also I'm just going to briefly touch the fact that this doesn't address 
spam as a problem at all, and in fact would make that problem 
overwhelmingly worse, as MTAs would be expected to accept mail from 
everywhere, and we obviously can't trust end user devices or ISP CPE to 
be secure against intrusion)


Scott Buettner
Front Range Internet Inc
NOC Engineer

On 3/26/2014 8:33 AM, Laszlo Hanyecz wrote:

Maybe you should focus on delivering email instead of refusing it.  Or just 
keep refusing it and trying to bill people for it, until you make yourself 
irrelevant.  The ISP based email made more sense when most end users - the 
people that we serve - didn't have persistent internet connections.  Today, 
most users are always connected, and can receive email directly to our own 
computers, without a middle man.  With IPv6 it's totally feasible since unique 
addressing is no longer a problem - there's no reason why every user can't have 
their own MTA.  The problem is that there are many people who are making money 
off of email - whether it's the sending of mail or the blocking of it - and so 
they're very interested in breaking direct email to get 'the users' to rely on 
them.  It should be entirely possible to build 'webmail' into home user CPEs or 
dedicated mailbox appliances, and let everyone deal with their own email 
delivery.  The idea of having to pay other people to host email for you is as 
obsolete as NAT-for-security, and this IPv6 SMTP thread is basically covering 
the same ground.  It boils down to: we have an old crappy system that works, 
and we don't want to change, because we've come to rely on the flaws of it and 
don't want them fixed.  In the email case, people have figured out how to make 
money doing it, so they certainly want to keep their control over it.

-Laszlo


On Mar 26, 2014, at 2:07 PM, Lamar Owen  wrote:


On 03/25/2014 10:51 PM, Jimmy Hess wrote:

[snip]

I would suggest the formation of an "IPv6 SMTP Server operator's club,"
with a system for enrolling certain IP address source ranges as  "Active
mail servers", active IP addresses and SMTP domain names under the
authority of a member.


...

As has been mentioned, this is old hat.

There is only one surefire way of doing away with spam for good, IMO.  No one 
is currently willing to do it, though.

That way?  Make e-mail cost; have e-postage.  No, I don't want it either.  But 
where is the pain point for spam where this becomes less painful?  If an 
enduser gets a bill for sending several thousand e-mails because they got owned 
by a botnet they're going to do something about it; get enough endusers with 
this problem and you'll get a class-action suit against OS vendors that allow 
the problem to remain a problem; you can get rid of the bots.  This will trim 
out a large part of spam, and those hosts that insist on sending unsolicited 
bulk e-mail will get billed for it.  That would also eliminate a lot of traffic 
on e-mail lists, too, if the subscribers had to pay the costs for each message 
sent to a list; I wonder what the cost would be for each post to a list the 
size of this one.  If spam ceases to be profitable, it will stop.

Of course, I reserve the right to be wrong, and this might all just be a pipe 
dream.  (and yes, I've thought about what sort of billing infrastructure 
nightmare this could be.)

Re: IPv6 isn't SMTP

[Tony Finch]

John Levine  wrote:
>
> There are also some odd things in the spec.  For example, according to
> RFC 5321 this is not a syntactically valid e-mail address:
>
> mailbox@[IPv6:2001:12:34:56::78:ab:cd]

You aren't allowed to use :: to abbreviate one zero hexadectet according
to RFC 5952.

http://www.rfc-editor.org/errata_search.php?eid=2467

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Malin: East 5 or 6. Moderate or rough, occasionally very rough in northwest.
Showers. Good, occasionally moderate.

Re: IPv6 isn't SMTP

[Blake Hudson]

Jimmy Hess wrote the following on 3/26/2014 7:12 PM:


The problem is with SMTP and is probably best addressed in the
application layer through updates to SMTP or required bolt-ons
(e.g SPF or similar); it was just simpler 



SPF is useful, but not a complete solution.

I'm curious what form you think these updates to SMTP would take?
What changes to SMTP protocol itself could really have a meaningful 
impact,


without frustrating, confusing, or terribly complicating the lives of 
millions of mail users?


The primary issues I see with SMTP as a protocol related to the lack of 
authentication and authorization. Take, for instance, the fact that the 
SMTP protocol requires a mail from: and rcpt to: address (more or less 
for authentication and authorization purposes), but then in the message 
allows the sender to specify a completely different set of sender and 
recipient information that gets displayed in the mail client.


SMTP is simple, it is reliable, and it works well for delivering a 
message, but it does not address authentication or authorization of 
remote users (to my knowledge). An extension to SMTP that provides some 
form of authentication and authorization for remote users could address 
the abuse concerns. For example, one could utilize a public key 
infrastructure through previously shared vcard or similar contact 
information to both authenticate and authorize a sender to be allowed to 
send email to a recipient. There are probably a few ways to accomplish 
the same goal, a PKI is just one example. This would allow one to 
configure his or her email as either 'default allow' to receive email 
from anyone at any time or 'default deny' to only allow authorized 
senders. There are some folks doing this today outside of SMTP, but 
without a mass effort these schemes will probably not take a strong 
foothold.


Implementing something like this takes some work in the mail client to 
be able to generate a private key and hold the public key info of 
others. Realistically, the key information could be exchanged and 
verified simply between clients at the remote ends without any SMTP 
server involvement, but that seems like a waste for servers to process 
and store messages that are going to be junked in the end that it would 
make sense that the SMTP servers could also be able to make these 
decisions server side. On the other hand, putting spam filtering in the 
hands of the end users could really untie the server operators from 
costly or cumbersome anti-SPAM efforts.


Any open source email clients want to take this task on and build an 
industry consensus? I'm all for having my emails tagged as 
trusted/authorized or untrusted/unauthorized in my email client. Once 
the level of untrusted, yet legitimate, messages drops to a low enough 
level I can stop accepting untrusted messages altogether.


--Blake

Re: misunderstanding scale

[Chip Marshall]

On 2014-03-26, Owen DeLong  sent:
> Then the spammers will grab /48s instead of /64s. Lather, rinse, repeat.
> 
> Admittedly, /48s are only 65,536 RBL entries per, but I still
> think that address-based reputations are a losing battle in an
> IPv6 world unless we provide some way for providers to hint at
> block sizes.
> 
> After all, if you start blocking a /64, what if it’s a /64
> shared by thousands of hosting customers at one provider
> offering virtuals?

It was brought to my attention in a parallel thread on Mailop
that such a mechanism does exist for allowing ISP to hint about
the size of customer allocations, at least in the RIPE database:

http://www.ripe.net/ripe/docs/ripe-513

So how do we make this universal and get ISPs to use it?

If we know customer sizes, it becomes much easier to do
reputation on a per-customer basis, which is probably granular
enough for a lot of cases.

-- 
Chip Marshall 
http://2bithacker.net/


pgpDfvwQUlHki.pgp
Description: PGP signature

Re: Access Lists for Subscriber facing ports?

[Mike]

On 03/27/2014 05:44 AM, Shawn L wrote:

With all of the new worms / denial of service / exploits, etc. that are
coming out, I'm wondering what others are using for access-lists on
residential subscriber-facing ports.

We've always taken the stance of 'allow unless there is a compelling reason
not to', but with everything that is coming out lately, I'm not sure that's
the correct position any more.
As a residential ISP, we have seen quite a lot of this in terms of both 
compromised customer computers spewing spam and ddos, as well as 
compromised customer routers participating in ddos attacks as well as 
dns redirection exploits for phishing and other purposes. I too am an 
advocate of staying out of the way as much as possible, but I've come 
around to realize that the average customer NEEDS to be protected 
against the consequences of their ignorance, MORE than they need the 
freedom to run a publicly accessible dns or ntp server.  We now have a 
default access list in place which locks down subscriber ports and 
prevents them from being a server on commonly exploited services like 
dns,ntp,smtp and so forth. The average customer neither knows nor cares, 
and suffers absolutely nothing because of it. What tipped it over for me 
was a rash of dns changers that exploited unknown to us default 
credentials in a number of subscriber modems, causing no end of 
customers who secretly depended on a set of DNS resolvers controlled by 
attackers that were performing poorly and resulting in 'why is it slow?' 
calls to my support staff. These devices should never have internet 
facing management, but they do and they did. I should also say that the 
acl's are also easily removable for any customer who asks. We don't make 
a big production out of it or anything, we just put the flag on their 
account and thats that.


Mike-

RE: [mailop] IPv6 DNSBL

[David Hofstee]

>> I suggest reputation on the reply-to domain also (if authenticated of 
>> course). No more running to other IPs / ESPs if you are a bad boy. You can 
>> integrate it in browsers and show it there too (watch out; don't enter your 
>> email address here because they will spam you or have spam evading practices 
>> [if no authentication takes place]). Show the reputation in the email client 
>> if possible.

>Most are not authenticated. The vast majority of SPAM I see is, among other 
>things, Joe Jobbed.

True. But the world must progress too. It would be nice if the spam-issue is 
better solved on IPv6 (than on IPv4). You would then have a reason to /not/ 
accept on IPv4 (and  give IPv6 a boost). 

There must be a good reason for people to get of their asses and start 
implementing things like DMARC. All the banks (!$%^) I talk to do not have any 
reason to implement it swiftly (they turn on p=none and then all progress 
stops). Frustrating that they are too lazy to implement a few DNS records. 

It only needs firm backing by 3+ large companies like Hotmail. Give everyone on 
IPv6 without DMARC a large spamscore (and publish that beforehand ;-) ). Give 
me ammunition and all corporates will move.


David Hofstee

Deliverability Management
MailPlus B.V. Netherlands (ESP)


-Oorspronkelijk bericht-
Van: Owen DeLong [mailto:o...@delong.com] 
Verzonden: Thursday, March 27, 2014 1:40 PM
Aan: David Hofstee
CC: Michael Peddemors; nanog@nanog.org
Onderwerp: Re: [mailop] IPv6 DNSBL


On Mar 27, 2014, at 2:37 AM, David Hofstee  wrote:

> I suggest reputation on the reply-to domain also (if authenticated of 
> course). No more running to other IPs / ESPs if you are a bad boy. You can 
> integrate it in browsers and show it there too (watch out; don't enter your 
> email address here because they will spam you or have spam evading practices 
> [if no authentication takes place]). Show the reputation in the email client 
> if possible.

Most are not authenticated. The vast majority of SPAM I see is, among other 
things, Joe Jobbed.

Owen

Access Lists for Subscriber facing ports?

[Shawn L]

With all of the new worms / denial of service / exploits, etc. that are
coming out, I'm wondering what others are using for access-lists on
residential subscriber-facing ports.

We've always taken the stance of 'allow unless there is a compelling reason
not to', but with everything that is coming out lately, I'm not sure that's
the correct position any more.

thanks

Re: IPv6 isn't SMTP

[Owen DeLong]

On Mar 27, 2014, at 3:24 AM, Franck Martin  wrote:

> 
> On Mar 26, 2014, at 11:26 PM, Owen DeLong  wrote:
> 
>> 
>> On Mar 26, 2014, at 8:12 PM, Robert Drake  wrote:
>> 
>>> 
>>> On 3/26/2014 10:16 PM, Franck Martin wrote:
 
 and user@2001:db8::1.25 with user@192.0.2.1:25. Who had the good idea to 
 use : for IPv6 addresses while this is the separator for the port in IPv4? 
 A few MTA are confused by it.
>>> At the network level the IPv6 address is just a big number.  No confusion 
>>> there.  At the plaintext level the naked IPv6 address should be wrapped in 
>>> square brackets.
>>> 
>>> From:
>>> http://tools.ietf.org/html/rfc3986#section-3.2.2
>>> 
>> 
>> Two errors, actually… As an RFC-821 address, it should be user@[IP]:port in 
>> both cases (user@[192.0.2.1]:25 and user@[2001:db8::1]:25).
>> 
> indeed, but MTAs are know to accept any kind of non RFC compliant emails and 
> trying to make some sense out of it… :P see 
> http://tools.ietf.org/html/rfc7103 which tries to address some of it in a 
> more deterministic way.
> 

Sure, but that doesn’t mean we should be sending random garbage deliberately.

Owen

Re: [mailop] IPv6 DNSBL

[Owen DeLong]

On Mar 27, 2014, at 2:37 AM, David Hofstee  wrote:

> I suggest reputation on the reply-to domain also (if authenticated of 
> course). No more running to other IPs / ESPs if you are a bad boy. You can 
> integrate it in browsers and show it there too (watch out; don't enter your 
> email address here because they will spam you or have spam evading practices 
> [if no authentication takes place]). Show the reputation in the email client 
> if possible.

Most are not authenticated. The vast majority of SPAM I see is, among other 
things, Joe Jobbed.

Owen

Re: IPv6 Security

[Owen DeLong]

On Mar 27, 2014, at 12:52 AM, sth...@nethelp.no wrote:

>>> No, it is LESS robust, because the client identifier changes when the
>>> SOFTWARE changes.  Around here, software changes MUCH more often than
>>> hardware.  Heck, even a dual-boot scenario breaks the client
>>> identifier stability.  Worse yet, DHCPv6 has created a scenario where
>>> a client's IPv4 connectivity and IPv6 connectivity break under
>>> /different/ scenarios, causing difficult-to-troubleshoot
>>> half-connectivity issues when either the hardware is replaced or the
>>> software is reloaded.
>> 
>> Any client whose DUID changes on software re-install has a very poor choice 
>> of default DUID and should be configurable for a better choice of DUID. That 
>> is not DHCPv6.FN"s fault.
> 
> It is reality. DHCPv6 needs to take reality into account.
> 
> DHCPv6 as defined in RFC 3315 does not offer client MAC address at all
> (thus making the job more difficult for a number of organizations).

Yes it does$B!D(B

What do you think $B!H(BLink Layer Address$B!I(B (RFC 3315, Section 9.1 
Type 3)
is? From RFC-3315 Section 9.4, it seems pretty clear that is exactly what
this is intended to be. True, it includes an additional 16 bits of media type,
but I don.FN"t see that as being a problem.


> All I've seen so far indicates that this was a deliberate choice by
> the DHCPv6 designers, and in my opinion a very poor one. Fortunately
> we now have RFC 6939 (DHCPv6 Client Link-Layer Address Option), and
> we're waiting for vendors to implement this. That solves one half of
> the problem.

Yes and no.

At the time RFC3315 was written, network cards changed independent of
motherboards on a regular basis and this fact was a source of great
consternation for DHCPv4 operators. Over time, that changed AFTER
RFC3315 was written, but if you read section 9.4, it seems pretty clear that
this change was anticipated by the authors and that DUID-LL was intended
for the situation we have today.

Clients failing to implement DUID-LL as defined in RFC-3315 can hardly be
blamed on DHCPv6.

> The other half is to actually let the DHCPv6 lease be based directly
> on the MAC address. The language in RFC 3315, as I read it, makes this
> difficult or impossible.

Reread section 9.4$B!D(B It seems not only possible, but recommended from my 
reading.

The problem isn.FN"t that the MAC address isnN"t allowed. The problem is 
that the clients
aren.FN"t properly using permanent MAC addresses as DUID.

Owen

Re: IPv6 isn't SMTP

[Franck Martin]

On Mar 26, 2014, at 11:26 PM, Owen DeLong  wrote:

> 
> On Mar 26, 2014, at 8:12 PM, Robert Drake  wrote:
> 
>> 
>> On 3/26/2014 10:16 PM, Franck Martin wrote:
>>> 
>>> and user@2001:db8::1.25 with user@192.0.2.1:25. Who had the good idea to 
>>> use : for IPv6 addresses while this is the separator for the port in IPv4? 
>>> A few MTA are confused by it.
>> At the network level the IPv6 address is just a big number.  No confusion 
>> there.  At the plaintext level the naked IPv6 address should be wrapped in 
>> square brackets.
>> 
>> From:
>> http://tools.ietf.org/html/rfc3986#section-3.2.2
>> 
> 
> Two errors, actually… As an RFC-821 address, it should be user@[IP]:port in 
> both cases (user@[192.0.2.1]:25 and user@[2001:db8::1]:25).
> 
indeed, but MTAs are know to accept any kind of non RFC compliant emails and 
trying to make some sense out of it… :P see http://tools.ietf.org/html/rfc7103 
which tries to address some of it in a more deterministic way.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: WISP or other options

[William Waites]

On Thu, Mar 27, 2014 at 05:09:05AM +, Warren Bailey wrote:
> It's not 802.11 and it doesn't act that way.

Actually most of the installations I've seen -- and my day job is
working with community networks around Scotland that have built all
manner of strange things -- the problems most often have nothing at
all to do with the physical layer. More often they're related to doing
things with spanning tree that we all learned in networking long ago
to not do, or running many layers of NAT because IP routing is not
understood. Things like that.

The only common RF problem is leaving the channel selection on
"auto". Which invariably means one radio, like an access point with a
sector antenna, can't hear the point to point link coming in to the
dish behind it and picks the wrong channel.

Again, yes, you're right, you have to understand how this stuff works
and think a little bit when you build, but your messages saying "It's
really really hard" are coming across a little like FUD.

> A pair of Air Fiber is like 3k USD, and at 24ghz you had better know 

The AF24 are also illegal here. Or rather the lower channel belongs to
the police, and the upper channel is limited to a very low output
power. We have a pair of these, with a special non-operational license
from Ofcom to put them through their paces. They do work, though they
are a pain to align and subject to rain fade. They are on the West
coast which is very rainy. Right now we're using them to measure rain
intensity rather than to carry real traffic (which we can't do with a
non-op license anyways).

-w

Re: WISP or other options

[William Waites]

On Thu, Mar 27, 2014 at 12:02:30AM -0400, Miles Fidelman wrote:
> Laser link, and pray for clear weather?

You'll have to pray really hard around here, especially in South
Queensferry down by the water... 

We actually have an FSO link between two tall buildings in South
Edinburgh. Only about 500m. It works pretty well except when the haar
rolls in.

Giant pain in the behind to align though, and given that the wind that
comes over the top of these tall buildings can be 5x that at ground
level, and gales happen several times a year, keeping them aligned
is... interesting...

-w

Re: WISP or other options

[William Waites]

On Thu, Mar 27, 2014 at 03:35:20AM +, Warren Bailey wrote:
> 
> You are screwed for LOS microwave, 60mbps on a microwave hope requires
> real life engineering to function correctly.

Well now, really. Yes it needs engineering, but nothing spectacularly
difficult. The upper bound on distance the OP needs is something like
10 miles which is peanuts. Any of your typical off the shelf 5GHz
stuff will do that, you can even just eyeball the alignment. The upper
5GHz band is not very crowded around here. You do need line of sight
which means spending a little time with a topo map.

You're right that it isn't as simple as just putting up some antennas,
leaving the kit at factory defaults and hoping, but that's not a very
high bar.

> towers

Rather conveniently there are lots of hills around here. A typical
can easily be something made out of standard scaffolding not more than
2.5m tall. You try to build them at the top of steep bits so that
people (and sheep) can't easily stand in front of the antennas.

> If you¹re looking for satellite

Satellite is a last resort, and almost always unnecessary even in very
remote places. It is also, as you point out, extremely expensive.

Best,
-w

Re: WISP or other options

[William Waites]

On Wed, Mar 26, 2014 at 10:30:27PM -0500, Nick wrote:
> 
> Does any have contacts in Edinburgh Scotland who can provide WISP
> service at the Hopetoun House and Dundas Castle. I would like to
> have 20-60mpbs to for 2 days of services.

There is a *chance* that we (http://hubs.net.uk/) can help. Our
network in Edinburgh is mostly constructed for serving areas to the
South -- the Lothians, the Borders, etc. and South Queensferry is to
the Northwest.

So one way of doing this would be to find an intermediate spot and
make two links. Briefly consulting a map there are a few candidates,
and for some, a temporary relay (the broadband wagon parked on a
hilltop) might work. It also looks as though there may be line of
sight to Scolocate in South Gyle which is a major datacentre where IX
Scotland is -- unfortunately we don't have anything on the roof there
at the moment.

If the event is for some sort of not for profit or academic related
thing other possibilities open up as well, it may be possible to use
one of the universities' networks to get most of the way there.

There are definitely possibilities, but it may well be too expensive
for such a short duration. Send me a mail off list if you want to
discuss in more detail.

> Our company's event planner claims there are no good ISP options in
> the area and wants us to go with satellite internet which is pricy
> and has high latency. Its worth noting both locations have ~7mpbs
> DLS.

It would be interesting to talk to this event planner...

Another option is bonded ADSL. I'd recommend Andrews and Arnold
(http://aa.net.uk/) for that. It's a bit ugly, and any DSL or FTTx is
very expensive for real use (BT Wholesale's tarrif for bandwidth on
their DSL carrier interconnect for resale is something like -L-40/Mbps
plus lots of other charges) but for a temporary situation it's not a
bad option.

Cheers,
-w

RE: [mailop] IPv6 DNSBL

[David Hofstee]

I suggest reputation on the reply-to domain also (if authenticated of course). 
No more running to other IPs / ESPs if you are a bad boy. You can integrate it 
in browsers and show it there too (watch out; don't enter your email address 
here because they will spam you or have spam evading practices [if no 
authentication takes place]). Show the reputation in the email client if 
possible.

And I would like fine-grained complaining possible (so everyone can filter like 
the big boys can, one might need the 'ham' numbers too). But you want to be 
sure such numbers are authentic.


David Hofstee

Deliverability Management
MailPlus B.V. Netherlands (ESP)


-Oorspronkelijk bericht-
Van: mailop [mailto:mailop-boun...@mailop.org] Namens Michael Peddemors
Verzonden: Thursday, March 27, 2014 1:06 AM
Aan: mai...@mailop.org
Onderwerp: Re: [mailop] IPv6 DNSBL

On 14-03-26 04:42 PM, John Levine wrote:
> As a reliable rule of thumb, any list that's large enough to be 
> interesting is also large enough to be compromised.
>
> I know people who have run whitelists at Returnpath, and I was in 
> charge of the never very successful Spamhaus whitelist.  The ones at 
> Returnpath always said that much of the job was dealing with bullshit 
> and deception from people trying to sneak into the whitelist.  At 
> Spamhaus, the main problem was that nearly all of the people willing 
> to go to the effort to be whitelisted didn't qualify, which wasn't 
> surprising, since people with good mail behavior rarely have trouble 
> getting their mail delivered.
>
> R's,
> John

Here Here..

(For instance, we recommend that people running filtering turn those off right 
away, eg SA..)

But we do see a lot of people discussing this here, and at the risk of making 
even more noise on this list on this subject, and maybe we should kill the 
thread there..

It would be interesting to get a poll of sorts.. hands please..
(You can reply off-list)

Options:

1) Only allow IPv4 to be used for MTA's
2) Create a Registry of Operators/IPs for MTA's on IPv6
3) Allow all IPv6 to be used for MTA's, and use blacklists
4) Other (Suggestions)

And if you believe in item 2, (personally I am happy with 1 or 2 and open to 4) 
what would you expect such a registry to look like?






-- 
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic

A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

___
mailop mailing list
mai...@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: why IPv6 isn't ready for prime time, SMTP edition

[Måns Nilsson]

Subject: Re: why IPv6 isn't ready for prime time, SMTP edition Date: Wed, Mar 
26, 2014 at 03:35:48PM -0400 Quoting John R. Levine (jo...@iecc.com):
> >>It must be nice to live in world where there is so little spam and
> >>other mail abuse that you don't have to do any of the anti-abuse
> >>things that real providers in the real world have to do.
> >
> >What is a real provider? And what in the email specifications tells us
> >that the email needs and solutions of any one individual, as long as they
> >are following protocol (which I'm quite convinced Mark is) are "unreal"?
> 
> A real provider is one that provides mail for real users, as opposed
> to someone who plays RFC language lawyer games.  I only have a few
> dozen users, but I can assure you I use a whole lot of different
> filtering approaches including DNSBLs to keep my users' mailboxes
> usable.

Ergo, ad hominem. Please quit doing that. 
As a side note I happen to run my own mail server without spam filters
-- it works for me. I might not be the norm, but then again, is there
really a norm? (A norm that transcends SMTP RFC reach, that is -- the
necessity to stick to protocol is not under debate)
 
> I must say it's pretty amusing that someone who works for the
> organization that published the original DNSBL seems to be ranting
> against them.

The ability to change ones mind when circumstances change is usually
seen as advantageous. Why not here?

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE +46 705 989668
This is a NO-FRILLS flight -- hold th' CANADIAN BACON!!


signature.asc
Description: Digital signature

Re: IPv6 Security

[Henri Wahl]

> It is reality. DHCPv6 needs to take reality into account.
>

One modest attempt to do so is dhcpy6d at
https://dhcpy6d.ifw-dresden.de. Still work in progress and might not fit
into every environment but helps some others.

Regards

-- 
Henri Wahl

IT Department
Leibniz-Institut fuer Festkoerper- u.
Werkstoffforschung Dresden

tel: (03 51) 46 59 - 797
email: h.w...@ifw-dresden.de
http://www.ifw-dresden.de

Nagios status monitor Nagstamon:
http://nagstamon.ifw-dresden.de

DHCPv6 server dhcpy6d:
http://dhcpy6d.ifw-dresden.de

IFW Dresden e.V., Helmholtzstrasse 20, D-01069 Dresden
VR Dresden Nr. 1369
Vorstand: Prof. Dr. Juergen Eckert, Dr. h.c. Dipl.-Finw. Rolf Pfrengle

-- 
Henri Wahl

IT Department
Leibniz-Institut fuer Festkoerper- u.
Werkstoffforschung Dresden

tel: (03 51) 46 59 - 797
email: h.w...@ifw-dresden.de
http://www.ifw-dresden.de

Nagios status monitor Nagstamon:
http://nagstamon.ifw-dresden.de

DHCPv6 server dhcpy6d:
http://dhcpy6d.ifw-dresden.de

IFW Dresden e.V., Helmholtzstrasse 20, D-01069 Dresden
VR Dresden Nr. 1369
Vorstand: Prof. Dr. Juergen Eckert, Dr. h.c. Dipl.-Finw. Rolf Pfrengle



signature.asc
Description: OpenPGP digital signature

Re: why IPv6 isn't ready for prime time, SMTP edition

[Mark Tinka]

On Thursday, March 27, 2014 09:48:09 AM Jim Popovitch wrote:

> 
> But a significant portion of it routes through London :-)
> 

> *cough *cough  co.tz to co.za, etc., etc.

Perhaps, but that does not mean it's all served by South 
African ISP's.

The London trombone is a separate issue.

Mark.


signature.asc
Description: This is a digitally signed message part.

Re: IPv6 Security

[sthaug]

> > No, it is LESS robust, because the client identifier changes when the
> > SOFTWARE changes.  Around here, software changes MUCH more often than
> > hardware.  Heck, even a dual-boot scenario breaks the client
> > identifier stability.  Worse yet, DHCPv6 has created a scenario where
> > a client's IPv4 connectivity and IPv6 connectivity break under
> > /different/ scenarios, causing difficult-to-troubleshoot
> > half-connectivity issues when either the hardware is replaced or the
> > software is reloaded.
> 
> Any client whose DUID changes on software re-install has a very poor choice 
> of default DUID and should be configurable for a better choice of DUID. That 
> is not DHCPv6?s fault.

It is reality. DHCPv6 needs to take reality into account.

DHCPv6 as defined in RFC 3315 does not offer client MAC address at all
(thus making the job more difficult for a number of organizations).
All I've seen so far indicates that this was a deliberate choice by
the DHCPv6 designers, and in my opinion a very poor one. Fortunately
we now have RFC 6939 (DHCPv6 Client Link-Layer Address Option), and
we're waiting for vendors to implement this. That solves one half of
the problem.

The other half is to actually let the DHCPv6 lease be based directly
on the MAC address. The language in RFC 3315, as I read it, makes this
difficult or impossible.

Steinar Haug, Nethelp consulting, sth...@nethelp.no

Re: misunderstanding scale

[Matthias Leisi]

On Thu, Mar 27, 2014 at 6:17 AM, Owen DeLong  wrote:


> > It only takes a single entry if you do not store /128s but that /64. Yes,
> > RBL lookups do not currently know how to handle this, but there are a
> > couple of good proposals around on how to do it.
>
> Then the spammers will grab /48s instead of /64s. Lather, rinse, repeat.
>
> Admittedly, /48s are only 65,536 RBL entries per, but I still think that
> address-based
> reputations are a losing battle in an IPv6 world unless we provide some
> way for providers
> to hint at block sizes.
>

That's why I believe having varying levels of granularity is the best trade
off between cache friendliness, administrative effort and implementation
complexity, independent on whether it's "default deny" or "default accept".

We either need to solve (or reduce the impact of) the DNS cache issue or we
need to solve the fixed-range issue.

Or IP-based reputation as we know it today is more or less dropped from the
anti-spam toolset when it comes to IPv6.

-- Matthias

Re: why IPv6 isn't ready for prime time, SMTP edition

[Jim Popovitch]

On Thu, Mar 27, 2014 at 3:38 AM, Mark Tinka  wrote:
> 
> Not all of 41/8 is served by South Africa :-).
> 


But a significant portion of it routes through London :-)


*cough *cough  co.tz to co.za, etc., etc.

-Jim P.

Re: why IPv6 isn't ready for prime time, SMTP edition

[Mark Tinka]

On Wednesday, March 26, 2014 08:26:14 PM Lamar Owen wrote:

> You don't.  Their upstream(s) in South Africa would bill
> them for outgoing e-mail.


Not all of 41/8 is served by South Africa :-).


Mark.


signature.asc
Description: This is a digitally signed message part.