Re: Level3 and AT&T Latency

[Chris Rogers]

AS13030 -> http://www.init7.net/en/status/

-Chris

On Wed, Nov 6, 2013 at 10:10 AM, Siegel, David wrote:

> As a matter of pure competitive intelligence gathering (i.e. I do not mean
> this as a rhetorical question), which providers list peering issues on
> their portal?  Particularly when they might be a bit more of an ongoing
> nature vs. a concrete outage?
>
>
> Dave
>
>
> -Original Message-
> From: Tassos Chatzithomaoglou [mailto:ach...@forthnet.gr]
> Sent: Tuesday, November 05, 2013 11:54 PM
> To: nanog@nanog.org
> Subject: Re: Level3 and AT&T Latency
>
> Unfortunately, many issues don't appear (deliberately?) as network events
> on their portal.
>
> --
> Tassos
>
> Jason Baugher wrote on 6/11/2013 06:46:
> > For what it's worth, Level3 finally told us they had a peering issue
> > with AT&T. They ended up re-routing traffic for the time being until
> > they identify the issue.
> >
> > Of course, for some reason a peering issue doesn't warrant a Network
> > Event on their portal...
> >
> >
> > On Tue, Nov 5, 2013 at 6:00 PM, David Siegrist  wrote:
> >
> >> I know we have been dealing with a Level 3, OC192 Fiber cut in PHX
> today.
> >>
> >> They just got it spliced back up.  Not sure if it is related to your
> >> latency.
> >>
> >> David
> >>
> >> -Original Message-
> >> From: Eric Williams [mailto:ewilli...@connectria.com]
> >> Sent: Tuesday, November 05, 2013 11:49 AM
> >> To: nanog@nanog.org
> >> Subject: Level3 and AT&T Latency
> >>
> >> Is anybody else seeing or having major latency between Level 3 and
> >> AT&T today?  We are multi-homed with Level 3 being one of our ISP's
> >> and had to divert traffic after seeing these issues.
> >>
> >> http://www.internetpulse.net/
> >>
> >> Eric
> >>
> >>
> >>
>
>
>

Re: Do you obfuscate email headers when reporting spam issues to clients?

[William Herrin]

On Wed, Nov 6, 2013 at 7:27 PM, Nonaht Leyte  wrote:
> As many here know, I spent 4 years on the receiving end of the
> abuse@savvisbox: when I was hired it was for multiple roles, but the
> abuse@was a primary.  Savvis had a significant spam problem when I
> arrived, and
> until just a few months before I left, had literally none.

Howdy,

Out of curiosity, what changed a few months before you left?

Regards,
Bill Herrin


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

Re: Do you obfuscate email headers when reporting spam issues to clients?

[William Herrin]

On Wed, Nov 6, 2013 at 5:46 PM, Anne P. Mitchell, Esq.
 wrote:
>> so aside from the abusers his customers will tend to
>> be heavy on single-recipient administrative emails rather than mailing
>> lists.
>
> Then, if they are truly one-to-one administrative emails, that's
> rather odd if they are generating a disproportionate number of
> spam complaints, dontcha think?  Unless they are inserting too
> much marketing into to them (always dicey).

Hi Anne,

In any given above-board hosting operation there are a whole lot of
things going on:

There's the small ad-hoc lists where an address is typoed and the mail
meant for Uncle George now goes to a random stranger.

There's the emails to formerly dead addresses now resurrected by new owners.

There's the folks who signed up for something and decided to
unsubscribe by reporting it as spam.

There the folks playing pranks on a friend by putting his address in a
bunch of "please contact me" web pages, causing the target to be
one-on-one solicited by a bunch of individual salesmen.

There are the server owners whose security was breached and their
happy web app is now being used to relay lots of spam.

And there's the spammer owned servers spewing out spam.

In each of these situations save the final one, obfuscating
information in the reported spam email only serves to make it
difficult or impossible to identify and stop the problem.

If you start with the assumption that the origin is a spammer until
proven otherwise it becomes a self-fulfilling prophecy -- because when
you report the obfuscated message, they can't track it down and fix
it!

Regards,
Bill Herrin


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

Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[Masataka Ohta]

valdis.kletni...@vt.edu wrote:

> You still haven't explained how "the memories of those who are at the table"
> help, when the NSA plant has very good reasons to say they're not an NSA
> plant, and you haven't explained how you can show they *are* a plant.

That is a problem between NSA, which recommended a person, and the
person recommended by NSA.

Masataka Ohta

Re: Do you obfuscate email headers when reporting spam issues to clients?

[Jimmy Hess]

On Wed, Nov 6, 2013 at 6:27 PM, Nonaht Leyte wrote:

Any abuse department which outright rejects (or claims they are unable to
> process) an obfuscated ("munged") complaint is not to be trusted - period.
>

This is very credible from someone admitting to scrubbing reports, of
information required by some abuse teams to appropriately process
complaints,  *NOT*.  You say scrub  Many would say:  munging  evidence,
 so that it  is no longer admissible,  or usable as supporting
documentation to suspend or terminate a subscriber's service.

There are abuse departments that would ignore such reports, or reply,
requesting information before proceeding, and they have that right;
especially,   if  the scrubbed reports  don't offer  sufficient evidence,
for their  particular investigation workflow to function.



> As a complainant, rather than the abuse@ recipient, I will always scrub my
> reports *thoroughly*, by removing the significant digits of time stamps,
> any unique identifiers I can find (from message-ID to unsubscribe links),
>



regardless of header obfuscation. Secondly, header obfuscation is NOT a
> waste of time for abuse@ - in fact, it is only marginally less useful than
> a "fully loaded" complaint. The reason is that even the smallest (or,


This is an assumption, that is only true in some cases.


> conversely, the most expertly organized) spammer will leave a complaint
> trail.  The complaints grow in importance as they grow in number: ten
>

Often the spammer will not leave a complaint trail;  they may very well
have sent 1000 messages,  that are logged with various different From:
addresses.

However,  non-spammers will also often leave a "complaint trail";   to give
an example: very often, non-spammers will even forward  their own mail to
another mailbox provider,  e.g. Yahoo/AOL,   and report duly forwarded spam
that arrives in their forwarding destination inbox,  as spam originating
from the forwarding provider.

Without the recipient address; the provider doing the mail forwarding has
no idea if it is the forwarded mail,  or  ordinarily sent mail  that is
being filed as spam.


--
-JH

Re: Do you obfuscate email headers when reporting spam issues to clients?

[Jon Lewis]

On Wed, 6 Nov 2013, Landon wrote:


Hello,

We (iWeb AS32613) are currently making great strides in getting out from
under the volume of reports received and getting on top of things.

How much trouble does your abuse department go to in order to obfuscate
headers when providing evidence of spamming activity regardless of if its
intentional/professional spammer activity or some kind of malware infection
allowing a third party to spam.  Especially for the pro spammers, we dont
want them list washing anything or worse yet becoming privy to spamtrap
data if the reporting party wasnt smart enough to obfuscate their own data
before sending in the report.


If you know you have pro spammers on your network, the question isn't how 
much to obfuscate spam complaints you receive...it's why haven't you 
terminated the customer(s)?


As for the rest, if the reporter wants obfuscation, it's on them to do it.

--
 Jon Lewis, MCP :)   |  I route
 |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Do you obfuscate email headers when reporting spam issues to clients?

[Nonaht Leyte]

> If you send him a complaint scrubbed in the manner you describe, he
> won't have enough information to act. You'd basically be wasting both
> his time and yours.

As many here know, I spent 4 years on the receiving end of the
abuse@savvisbox: when I was hired it was for multiple roles, but the
abuse@was a primary.  Savvis had a significant spam problem when I
arrived, and
until just a few months before I left, had literally none.

First of all, *every* abuse email should be seriously investigated,
regardless of header obfuscation. Secondly, header obfuscation is NOT a
waste of time for abuse@ - in fact, it is only marginally less useful than
a "fully loaded" complaint. The reason is that even the smallest (or,
conversely, the most expertly organized) spammer will leave a complaint
trail.  The complaints grow in importance as they grow in number: ten
complaints in the morning abuse email tells me that there is a serious
problem with the sender, even if every single header and other identifying
information is removed from the complaints.  Ten complaints may not
indicate malice (although it usually does), but it does tell abuse@ to
start their resolution clock.

Any abuse department which outright rejects (or claims they are unable to
process) an obfuscated ("munged") complaint is not to be trusted - period.
The abuse department that wont respond to munging is deliberately closing
their eyes to abuse on their network.  Any abuse@ that fails to immediately
act on reports of third-party beneficiaries (for example, drop boxes or
ordering websites) on their network is doing the same thing.

As a complainant, rather than the abuse@ recipient, I will always scrub my
reports *thoroughly*, by removing the significant digits of time stamps,
any unique identifiers I can find (from message-ID to unsubscribe links),
and anything else I think can possibly be used to listwash.  The only
exception to this is if I am reporting to someone I know and explicitly
trust (and there are damn few of those left).

As the abuse@ guy, I would strongly encourage scrubbed reports, even
reports which prove nothing other than an email went out that was unwanted
(as opposed to unsolicited - it's not uncommon for people to make "spam
complaints" rather than unsubscribe from mailings they legitimately
subscribed to).  There are a multitude of internal [& proprietary] tools at
most ISPs that can lead to the appropriate determination as to what is or
isn't spamming, but for the tools to be used, there needs to be a starting
complaint(s).

//Alif




On Wed, Nov 6, 2013 at 4:40 PM, William Herrin  wrote:

> On Wed, Nov 6, 2013 at 5:16 PM, Anne P. Mitchell, Esq.
>  wrote:
> > Because this is an issue inherent primarily with bulk mail,
> > we remove all identifying information *except* the unsub link,
> > which *should* have a unique identifying token embedded
> > within, from which the sender *should* be able to determine
> > the complainant's email address.
>
> Hi Anne,
>
> Judging from Landon's web page a vanishingly small percentage of his
> customers are in the opt-in mailing list business. He's in the generic
> hosting business, so aside from the abusers his customers will tend to
> be heavy on single-recipient administrative emails rather than mailing
> lists.
>
> If you send him a complaint scrubbed in the manner you describe, he
> won't have enough information to act. You'd basically be wasting both
> his time and yours.
>
>
> > Failure to do so can (and usually does)
> > result in termination of their accreditation
>
> Accreditation of what?
>
> Regards,
> Bill Herrin
>
>
>
> --
> William D. Herrin  her...@dirtside.com  b...@herrin.us
> 3005 Crane Dr. .. Web: 
> Falls Church, VA 22042-3004
>
>

Re: Do you obfuscate email headers when reporting spam issues to clients?

[Jimmy Hess]

On Wed, Nov 6, 2013 at 12:30 PM, Landon  wrote:

> Hello,
>
 How much trouble does your abuse department go to in order to obfuscate

> headers when providing evidence of spamming activity regardless of if it’s
> intentional/professional spammer activity or some kind of malware infection
> allowing a third party to spam.
>

I suggest using separate spam traps for reporting,  from spam traps used to
develop filters and blacklists, seeded/published  at similar places.

Don't report spam hitting secret spamtraps;  just use what is received at
secret spam traps to develop the spam corpus, blacklists, or filtering
rules.



There are exceptions,  but  when reporting spam:  the recipient needs
actionable information. Not just  someone claiming that there is spam
from them.  If they are the upstream IP network abuse contact
or operator of a large mail server, they should see who it came from,  who
it went to,   the timestamps, message ids, and full headers.

The stuff you could remove to make "list washing"  hard or disguise a spam
trap,  is the same stuff  the receiver of your report needs, to efficiently
and effectively help identify their outbreak,  and put a stop to the spam,
   so you're also making  it hard
for legitimate contacts   to   find the appropriate log entry, and match
the e-mail message to the account it came from.


--
-JH

Re: Level3 and AT&T Latency

[Job Snijders]

On Wed, Nov 06, 2013 at 10:51:08PM +, J.J. Mc Kenna wrote:
> Comcast to XO due to Comcast's TATA peering issue.
> 
> Ongoing.

I'd love to see verifiable public data to back up that claim. 

Kind regards,

Job



pgpkM0i4UwL6b.pgp
Description: PGP signature

RE: Level3 and AT&T Latency

[J.J. Mc Kenna]

Comcast to XO due to Comcast's TATA peering issue.

Ongoing.

J.J. 


From: Siegel, David 
Sent: Wednesday, November 06, 2013 7:10 AM
To: Tassos Chatzithomaoglou; nanog@nanog.org
Subject: [GRAYMAIL] RE: Level3 and AT&T Latency

As a matter of pure competitive intelligence gathering (i.e. I do not mean this 
as a rhetorical question), which providers list peering issues on their portal? 
 Particularly when they might be a bit more of an ongoing nature vs. a concrete 
outage?


Dave


-Original Message-
From: Tassos Chatzithomaoglou [mailto:ach...@forthnet.gr]
Sent: Tuesday, November 05, 2013 11:54 PM
To: nanog@nanog.org
Subject: Re: Level3 and AT&T Latency

Unfortunately, many issues don't appear (deliberately?) as network events on 
their portal.

--
Tassos

Jason Baugher wrote on 6/11/2013 06:46:
> For what it's worth, Level3 finally told us they had a peering issue
> with AT&T. They ended up re-routing traffic for the time being until
> they identify the issue.
>
> Of course, for some reason a peering issue doesn't warrant a Network
> Event on their portal...
>
>
> On Tue, Nov 5, 2013 at 6:00 PM, David Siegrist  wrote:
>
>> I know we have been dealing with a Level 3, OC192 Fiber cut in PHX today.
>>
>> They just got it spliced back up.  Not sure if it is related to your
>> latency.
>>
>> David
>>
>> -Original Message-
>> From: Eric Williams [mailto:ewilli...@connectria.com]
>> Sent: Tuesday, November 05, 2013 11:49 AM
>> To: nanog@nanog.org
>> Subject: Level3 and AT&T Latency
>>
>> Is anybody else seeing or having major latency between Level 3 and
>> AT&T today?  We are multi-homed with Level 3 being one of our ISP's
>> and had to divert traffic after seeing these issues.
>>
>> http://www.internetpulse.net/
>>
>> Eric
>>
>>
>>

Re: Do you obfuscate email headers when reporting spam issues to clients?

[Anne P. Mitchell, Esq.]

> so aside from the abusers his customers will tend to
> be heavy on single-recipient administrative emails rather than mailing
> lists.

Then, if they are truly one-to-one administrative emails, that's rather odd if 
they are generating a disproportionate number of spam complaints, dontcha 
think?  Unless they are inserting too much marketing into to them (always 
dicey).

>> Failure to do so can (and usually does)
>> result in termination of their accreditation
> 
> Accreditation of what?

I'll respond more fully to this offlist, as it's OT, but the short answer is 
that we accredit email senders who are adhering to best practices (not unlike 
ReturnPath, only we're the other white meat).

Anne

Anne P. Mitchell, Esq.
Author: Section 6 of the CAN-SPAM Act of 2003
CEO/President
Institute for Social Internet Public Policy
http://www.ISIPP.com 
Member, Cal. Bar Cyberspace Law Committee

How do you get to the inbox instead of the spam filter?  SuretyMail!
Helping businesses keep their email out of the junk folder since 1998
http://www.isipp.com/SuretyMail

Re: Do you obfuscate email headers when reporting spam issues to clients?

[William Herrin]

On Wed, Nov 6, 2013 at 5:16 PM, Anne P. Mitchell, Esq.
 wrote:
> Because this is an issue inherent primarily with bulk mail,
> we remove all identifying information *except* the unsub link,
> which *should* have a unique identifying token embedded
> within, from which the sender *should* be able to determine
> the complainant's email address.

Hi Anne,

Judging from Landon's web page a vanishingly small percentage of his
customers are in the opt-in mailing list business. He's in the generic
hosting business, so aside from the abusers his customers will tend to
be heavy on single-recipient administrative emails rather than mailing
lists.

If you send him a complaint scrubbed in the manner you describe, he
won't have enough information to act. You'd basically be wasting both
his time and yours.


> Failure to do so can (and usually does)
> result in termination of their accreditation

Accreditation of what?

Regards,
Bill Herrin



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

Re: Reverse DNS RFCs and Recommendations

[Mark Andrews]

In message <5964ada4-8fcf-4fce-9e64-7474ccae5...@consultant.com>, Cutler James 
R writes:
> Dynamic DNS providers will undoubtably endeavor to make money from 
> and SRV entries for publicly-reachable services in SOHO and home
> networks. Dynamic DNS providers are normally not delegated authority to
> provide PTR records for ISP managed addresses, making provision of
> complementary  and PTR records highly unlikely.
>
> Because of the cost of scaling and delegation issues I agree with Jason
> and see no compelling business case for rDNS services for SOHO or
> residential users.

Did you BOTHER TO READ the draft before commenting as the comments
imply that you haven't.  Nothing in the draft is more difficult
than is what is already being done inside enterprises networks today
every single minute of the day.

Enterprise DHCP servers construct DNS PTR records and add them to
the DNS using TSIG signed UPDATE requests.  They do it at one per
machine.

This is DHCP servers constucting a DNS KEY record and adding it to
the DNS using TSIG signed UPDATE requests.  The amount is ONE per
customer.  ISP's already support a PTR record per customer so your
scale arguement is blown out of the water.  This is draft addresses
the delegation issue by automating it so that any CPE device from
any manufacture can perform the delegation without humans being
involved.

Mark

> It's dead,
>   Jim
>
> James R. Cutler
> james.cut...@consultant.com

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Do you obfuscate email headers when reporting spam issues to clients?

[Anne P. Mitchell, Esq.]

> On Wed, Nov 6, 2013 at 1:30 PM, Landon  wrote:
>> How much trouble does your abuse department go to in order to obfuscate
>> headers when providing evidence of spamming activity regardless of if it?s
>> intentional/professional spammer activity or some kind of malware infection
>> allowing a third party to spam.  Especially for the pro spammers, we don?t
>> want them list washing anything or worse yet becoming privy to spamtrap
>> data if the reporting party wasn?t smart enough to obfuscate their own data
>> before sending in the report.
> 
> Howdy,
> 
> It depends on the exact situation, but the general-purpose answer is:
> none. zero. zip.
> 
> The customer usually can't act on your information unless he can line
> it up with an entry in his own logs. He needs lots of details in the
> headers to figure out which computer or which of his users the message
> came from. And he needs that information to determine whether the
> message really came from his system -- headers get forged, you know.

Because this is an issue inherent primarily with bulk mail, we remove all 
identifying information *except* the unsub link, which *should* have a unique 
identifying token embedded within, from which the sender *should* be able to 
determine the complainant's email address.  And, if there is no such link, we 
use that as an opportunity to educate them as to *why* they need to include 
such a link (mind you, in order to be accredited with us the sender has to have 
already demonstrated that they comply with including an unsub link, but because 
many of our accreditation customers are ESPs, their customers may sometimes not 
be modelling 100% of best practices).

Regardless of unsub link, or anything else, if we get a spam complaint against 
one of our customers, we hold their feet to the fire, and require them to 
explain exactly how the particular list was built, how the address was 
acquired, etc..  Failure to do so can (and usually does) result in termination 
of their accreditation - in the case of an ESP, they have to take corrective 
measures against their spamming customer or the ESP will lose their 
accreditation.

Anne

Anne P. Mitchell, Esq.
Author: Section 6 of the CAN-SPAM Act of 2003
CEO/President
Institute for Social Internet Public Policy
http://www.ISIPP.com 
Member, Cal. Bar Cyberspace Law Committee

How do you get to the inbox instead of the spam filter?  SuretyMail!
Helping businesses keep their email out of the junk folder since 1998
http://www.isipp.com/SuretyMail

Re: Do you obfuscate email headers when reporting spam issues to clients?

[Doug Clements]

On Wed, Nov 6, 2013 at 4:45 PM, William Herrin  wrote:

> Incidentally, I'd suggest that an ounce of prevention is worth a pound
> of cure. Simply block outbound tcp port 25 for new hosting customers
> on a "tell me if you want it open" basis.
>
>
Or to thwart those clever spammers, block inbound SYN/ACK packets with a
source port of 25. This catches the ones who send SYNs out other providers
with your network's source addresses which bypasses most simple ACLs.

--Doug

Re: Recovery mode on Juniper M7i

[Jeff Sorrels]

Direct access to the bootstrap loader should bypass any access 
restrictions configured on the box.  However, it sounds like the device 
is not dropping into single-user mode.


I would suggest removing and wiping the CF card.  Then boot from 
alternative media (USB) and snapshot on to the blank card.


Cheers,
Jeff




On 11/6/2013 3:28 PM, Pedro Cavaca wrote:

Maybe you're not doing anything wrong and someone tweaked the routers and
marked the console as insecure, a previous owner maybe?

http://superuser.com/questions/85536/securing-freebsd-in-single-user-mode

http://www.freebsd.org/cgi/man.cgi?query=boot&sektion=8

HTH.


On 6 November 2013 21:11, Anurag Bhatia  wrote:


Hello everyone!


Greetings of the day.


I am kind of (badly) stuck with multiple routers and not able to recover
the root password. It's Juniper M7i. I have followed the Juniper support
page as given here -

http://www.juniper.net/techpubs/en_US/junos/topics/task/configuration/authentication-root-password-recovering.htmland
strange enough that it worked with one of routers I have but failed on
rest all.


I am getting stuck on Step #12. As I give "boot -s" to get into single user
mode of BSD, system next asks me for root password and hence I am out of
luck to get into "recovery mode". I tried pressing enter on that prompt as
well but no luck. I am connecting to router via console and do have
physical access to router(s).


Was wondering if someone has seen similar issues and could guide on what I
am doing wrong? Most of other help pages I have seen on net have same exact
steps as given on that page.




Thanks.
--


Anurag Bhatia
anuragbhatia.com

Linkedin  |
Twitter
Skype: anuragbhatia.com



--
Jeff Sorrels
Network Administrator
KanREN, Inc
jlsorr...@kanren.net
785-856-9820, #2

Re: Recovery mode on Juniper M7i

[Anurag Bhatia]

Hi sure


Please find screenshot...


@Mehmet - I checked that in daytime and didn't found anything specific
about that version. Sorry don't have it handy with me right now but will
check exact version again in morning and will update you.


On Wed, Nov 6, 2013 at 10:33 PM, Rakesh M  wrote:

> Can you paste in the output after  'boot -s' , I came across several
> issues while recovering Root Password, But never faced this :)
>
>
> On Thu, Nov 7, 2013 at 2:41 AM, Anurag Bhatia  wrote:
>
>> Hello everyone!
>>
>>
>> Greetings of the day.
>>
>>
>> I am kind of (badly) stuck with multiple routers and not able to recover
>> the root password. It's Juniper M7i. I have followed the Juniper support
>> page as given here -
>>
>> http://www.juniper.net/techpubs/en_US/junos/topics/task/configuration/authentication-root-password-recovering.htmland
>> strange enough that it worked with one of routers I have but failed on
>> rest all.
>>
>>
>> I am getting stuck on Step #12. As I give "boot -s" to get into single
>> user
>> mode of BSD, system next asks me for root password and hence I am out of
>> luck to get into "recovery mode". I tried pressing enter on that prompt as
>> well but no luck. I am connecting to router via console and do have
>> physical access to router(s).
>>
>>
>> Was wondering if someone has seen similar issues and could guide on what I
>> am doing wrong? Most of other help pages I have seen on net have same
>> exact
>> steps as given on that page.
>>
>>
>>
>>
>> Thanks.
>> --
>>
>>
>> Anurag Bhatia
>> anuragbhatia.com
>>
>> Linkedin  |
>> Twitter
>> Skype: anuragbhatia.com
>>
>
>


-- 


Anurag Bhatia
anuragbhatia.com

Linkedin  |
Twitter
Skype: anuragbhatia.com

Re: Recovery mode on Juniper M7i

[Rakesh M]

Can you paste in the output after  'boot -s' , I came across several issues
while recovering Root Password, But never faced this :)


On Thu, Nov 7, 2013 at 2:41 AM, Anurag Bhatia  wrote:

> Hello everyone!
>
>
> Greetings of the day.
>
>
> I am kind of (badly) stuck with multiple routers and not able to recover
> the root password. It's Juniper M7i. I have followed the Juniper support
> page as given here -
>
> http://www.juniper.net/techpubs/en_US/junos/topics/task/configuration/authentication-root-password-recovering.htmland
> strange enough that it worked with one of routers I have but failed on
> rest all.
>
>
> I am getting stuck on Step #12. As I give "boot -s" to get into single user
> mode of BSD, system next asks me for root password and hence I am out of
> luck to get into "recovery mode". I tried pressing enter on that prompt as
> well but no luck. I am connecting to router via console and do have
> physical access to router(s).
>
>
> Was wondering if someone has seen similar issues and could guide on what I
> am doing wrong? Most of other help pages I have seen on net have same exact
> steps as given on that page.
>
>
>
>
> Thanks.
> --
>
>
> Anurag Bhatia
> anuragbhatia.com
>
> Linkedin  |
> Twitter
> Skype: anuragbhatia.com
>

Re: Do you obfuscate email headers when reporting spam issues to clients?

[William Herrin]

On Wed, Nov 6, 2013 at 1:30 PM, Landon  wrote:
> We (iWeb AS32613) are currently making great strides in getting out from
> under the volume of reports received and getting on top of things.

Incidentally, I'd suggest that an ounce of prevention is worth a pound
of cure. Simply block outbound tcp port 25 for new hosting customers
on a "tell me if you want it open" basis. Don't make 'em jump through
hoops: if they want it open, open it. But for everybody who doesn't
tell you they want it open, keep it closed. Then analyze your data
traffic for a month or two and close the port on any old customers
that haven't sent any email.

By doing so, you restrict the potential source of the problem to just
those customers who intentionally generate email from their hosted
service. Non-email using customers who get hit with worms and spambots
will bounce off your shield. Also, you force spammers to bring
themselves to your notice before they can send any mail -- something
they're disinclined to do.

Regards,
Bill Herrin


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

Re: Recovery mode on Juniper M7i

[Pedro Cavaca]

Maybe you're not doing anything wrong and someone tweaked the routers and
marked the console as insecure, a previous owner maybe?

http://superuser.com/questions/85536/securing-freebsd-in-single-user-mode

http://www.freebsd.org/cgi/man.cgi?query=boot&sektion=8

HTH.


On 6 November 2013 21:11, Anurag Bhatia  wrote:

> Hello everyone!
>
>
> Greetings of the day.
>
>
> I am kind of (badly) stuck with multiple routers and not able to recover
> the root password. It's Juniper M7i. I have followed the Juniper support
> page as given here -
>
> http://www.juniper.net/techpubs/en_US/junos/topics/task/configuration/authentication-root-password-recovering.htmland
> strange enough that it worked with one of routers I have but failed on
> rest all.
>
>
> I am getting stuck on Step #12. As I give "boot -s" to get into single user
> mode of BSD, system next asks me for root password and hence I am out of
> luck to get into "recovery mode". I tried pressing enter on that prompt as
> well but no luck. I am connecting to router via console and do have
> physical access to router(s).
>
>
> Was wondering if someone has seen similar issues and could guide on what I
> am doing wrong? Most of other help pages I have seen on net have same exact
> steps as given on that page.
>
>
>
>
> Thanks.
> --
>
>
> Anurag Bhatia
> anuragbhatia.com
>
> Linkedin  |
> Twitter
> Skype: anuragbhatia.com
>

Re: Recovery mode on Juniper M7i

[Mehmet Akcin]

On Nov 6, 2013, at 1:11 PM, Anurag Bhatia  wrote:

> Hello everyone!
> 
> 
> Greetings of the day.
> 
> 
> I am kind of (badly) stuck with multiple routers and not able to recover
> the root password. It's Juniper M7i. I have followed the Juniper support
> page as given here -
> http://www.juniper.net/techpubs/en_US/junos/topics/task/configuration/authentication-root-password-recovering.htmland
> strange enough that it worked with one of routers I have but failed on
> rest all.
> 

what's your junos version?

Re: Reverse DNS RFCs and Recommendations

[Mark Andrews]

In message <5964ada4-8fcf-4fce-9e64-7474ccae5...@consultant.com>, Cutler James 
R writes:
> On Nov 6, 2013, at 9:02 AM, Livingood, Jason
>  wrote:
>
> > Reverse DNS for (typical) residential customer IPv6 addresses is dead,
> > people just haven't come to grips with it just yet.;-)
> >
> >
> > When publicly-reachable services in home networks are created that may
> > be a different matter of course. But it is hard to imagine an ISP
> > automatically or dynamically generating reverse records for all the IPv6
> > addresses handed out to your average residential users.
> >
> > Jason

This discussion is currently NOT about ISP's generating PTR records
for IPv6 reverse.

It is about the automatic delegation of the DNS reverse namespace
to to servers under customer control when the CPE device requests
it as part of the Prefix Delegation request.  This is about a adding
KEY, DS and NS records at the delegation point in a secure manner.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Do you obfuscate email headers when reporting spam issues to clients?

[William Herrin]

On Wed, Nov 6, 2013 at 1:30 PM, Landon  wrote:
> How much trouble does your abuse department go to in order to obfuscate
> headers when providing evidence of spamming activity regardless of if it’s
> intentional/professional spammer activity or some kind of malware infection
> allowing a third party to spam.  Especially for the pro spammers, we don’t
> want them list washing anything or worse yet becoming privy to spamtrap
> data if the reporting party wasn’t smart enough to obfuscate their own data
> before sending in the report.

Howdy,

It depends on the exact situation, but the general-purpose answer is:
none. zero. zip.

The customer usually can't act on your information unless he can line
it up with an entry in his own logs. He needs lots of details in the
headers to figure out which computer or which of his users the message
came from. And he needs that information to determine whether the
message really came from his system -- headers get forged, you know.

If he can line it up with an entry in his logs then, if he's a
spammer, he knows what address the message was sent to rendering your
obfuscation pointless. And by now spammers are very good at list
scrubbing from the slightest bit of uniquely identifiable information
they can get back. Assuming they bother, which many don't.

It does depend on the situation though. You shouldn't be forwarding
the customer 200 spam complaints. After a small sample of messages he
either has enough information to track the source of the problem or he
is the problem.

Also, when I bounce spam, I scrub my antispam engine's report from the
bounce. No point telling the spammer how he failed to reach me.

Regards,
Bill Herrin


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

Recovery mode on Juniper M7i

[Anurag Bhatia]

Hello everyone!


Greetings of the day.


I am kind of (badly) stuck with multiple routers and not able to recover
the root password. It's Juniper M7i. I have followed the Juniper support
page as given here -
http://www.juniper.net/techpubs/en_US/junos/topics/task/configuration/authentication-root-password-recovering.htmland
strange enough that it worked with one of routers I have but failed on
rest all.


I am getting stuck on Step #12. As I give "boot -s" to get into single user
mode of BSD, system next asks me for root password and hence I am out of
luck to get into "recovery mode". I tried pressing enter on that prompt as
well but no luck. I am connecting to router via console and do have
physical access to router(s).


Was wondering if someone has seen similar issues and could guide on what I
am doing wrong? Most of other help pages I have seen on net have same exact
steps as given on that page.




Thanks.
-- 


Anurag Bhatia
anuragbhatia.com

Linkedin  |
Twitter
Skype: anuragbhatia.com

Do you obfuscate email headers when reporting spam issues to clients?

[Landon]

Hello,

We (iWeb AS32613) are currently making great strides in getting out from
under the volume of reports received and getting on top of things.

How much trouble does your abuse department go to in order to obfuscate
headers when providing evidence of spamming activity regardless of if it’s
intentional/professional spammer activity or some kind of malware infection
allowing a third party to spam.  Especially for the pro spammers, we don’t
want them list washing anything or worse yet becoming privy to spamtrap
data if the reporting party wasn’t smart enough to obfuscate their own data
before sending in the report.

So basically in order to be able to provide some evidence to clients they
can use in the case of an infection of some type but not give away too much
information to professional spammers we need to find a balance.  I’m not
sure if it’s worthwhile going to too much trouble on this since basically
regardless of the data they get sent they are going to be nuked if they are
actual spammers anyway.

-- 
Landon Stewart 

Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[Valdis . Kletnieks]

On Wed, 06 Nov 2013 08:50:06 +0900, Masataka Ohta said:
> valdis.kletni...@vt.edu wrote:
>
> >>> How do you intend to *find* the agents
> >>> who were hired at a government agency's under-the-table request that
> >>> never had a written record that the company had access to?
> >>
> >> By memories of those who are at the table.

> Hint: I'm not talking about a way to have perfect security. I'm talking
> about possible/good/recommended approach to improve the security without
> witch hunting.

You still haven't explained how "the memories of those who are at the table"
help, when the NSA plant has very good reasons to say they're not an NSA
plant, and you haven't explained how you can show they *are* a plant.


pgp1cbvQ4tHqW.pgp
Description: PGP signature

RE: Level3 and AT&T Latency

[Siegel, David]

As a matter of pure competitive intelligence gathering (i.e. I do not mean this 
as a rhetorical question), which providers list peering issues on their portal? 
 Particularly when they might be a bit more of an ongoing nature vs. a concrete 
outage?


Dave


-Original Message-
From: Tassos Chatzithomaoglou [mailto:ach...@forthnet.gr] 
Sent: Tuesday, November 05, 2013 11:54 PM
To: nanog@nanog.org
Subject: Re: Level3 and AT&T Latency

Unfortunately, many issues don't appear (deliberately?) as network events on 
their portal.

--
Tassos

Jason Baugher wrote on 6/11/2013 06:46:
> For what it's worth, Level3 finally told us they had a peering issue 
> with AT&T. They ended up re-routing traffic for the time being until 
> they identify the issue.
>
> Of course, for some reason a peering issue doesn't warrant a Network 
> Event on their portal...
>
>
> On Tue, Nov 5, 2013 at 6:00 PM, David Siegrist  wrote:
>
>> I know we have been dealing with a Level 3, OC192 Fiber cut in PHX today.
>>
>> They just got it spliced back up.  Not sure if it is related to your 
>> latency.
>>
>> David
>>
>> -Original Message-
>> From: Eric Williams [mailto:ewilli...@connectria.com]
>> Sent: Tuesday, November 05, 2013 11:49 AM
>> To: nanog@nanog.org
>> Subject: Level3 and AT&T Latency
>>
>> Is anybody else seeing or having major latency between Level 3 and 
>> AT&T today?  We are multi-homed with Level 3 being one of our ISP's 
>> and had to divert traffic after seeing these issues.
>>
>> http://www.internetpulse.net/
>>
>> Eric
>>
>>
>>

Re: Reverse DNS RFCs and Recommendations

[Cutler James R]

On Nov 6, 2013, at 9:02 AM, Livingood, Jason 
 wrote:

> Reverse DNS for (typical) residential customer IPv6 addresses is dead,
> people just haven¹t come to grips with it just yetŠ ;-)
> 
> 
> When publicly-reachable services in home networks are created that may be
> a different matter of course. But it is hard to imagine an ISP
> automatically or dynamically generating reverse records for all the IPv6
> addresses handed out to your average residential users.
> 
> Jason
> 
> 
> On 11/5/13, 12:31 AM, "Lee Howard"  wrote:
> 
>> http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00
>> 
>> 
>> It would be great to have this conversation in the IETF Homenet WG, as
>> well as DNSops.
>> This would solve the gaps I identified.  Not sure why I, as an ISP, would
>> spend money on this.
>> 
>> Lee
>> 
>> 
>> 
> 
> 

Dynamic DNS providers will undoubtably endeavor to make money from  and SRV 
entries for publicly-reachable services in SOHO and home networks. Dynamic DNS 
providers are normally not delegated authority to provide PTR records for ISP 
managed addresses, making provision of complementary  and PTR records 
highly unlikely.  

Because of the cost of scaling and delegation issues I agree with Jason and see 
no compelling business case for rDNS services for SOHO or residential users. 

It’s dead,
Jim 

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






signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Reverse DNS RFCs and Recommendations

[Livingood, Jason]

Reverse DNS for (typical) residential customer IPv6 addresses is dead,
people just haven¹t come to grips with it just yetŠ ;-)


When publicly-reachable services in home networks are created that may be
a different matter of course. But it is hard to imagine an ISP
automatically or dynamically generating reverse records for all the IPv6
addresses handed out to your average residential users.

Jason


On 11/5/13, 12:31 AM, "Lee Howard"  wrote:

>http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00
>
>
>It would be great to have this conversation in the IETF Homenet WG, as
>well as DNSops.
>This would solve the gaps I identified.  Not sure why I, as an ISP, would
>spend money on this.
>
>Lee
>
>
>

Re: DNS and nxdomain hijacking

[Livingood, Jason]

On 11/5/13, 11:01 PM, "Mark Andrews"  wrote:

>In message <20131106033003.gb6...@dyn.com>, Andrew Sullivan writes:
>> On Tue, Nov 05, 2013 at 07:57:59PM -0500, Phil Bedard wrote:
>> > 
>> > I think every major residential ISP in the US has been doing this for
>>5+
>> > years now.
>> 
>> Comcast doesn't, because it breaks DNSSEC.
>
>Only if you are validating.

Exactly. And this was one of the central arguments that helped defeat the
DNS redirection portions of SOPA/PIPA/ProtectIP/COICA.

Jason

Re: DNS and nxdomain hijacking

[Livingood, Jason]

On 11/5/13, 7:57 PM, "Phil Bedard"  wrote:

>I think every major residential ISP in the US has been doing this for 5+
>years now.  I worked at one provider who made a pretty decent chunk of
>change off the monthly ad revenue and that was 6 years ago.  People typo a
>lot of URLs.  

There¹s less money in it that you¹d think and the monetization rates are
declining.

Jason

Re: DNS and nxdomain hijacking

[Livingood, Jason]

You can find a fairly good overview at 
http://tools.ietf.org/html/draft-livingood-dns-redirect-03

Comcast does not do this, see 
http://corporate.comcast.com/comcast-voices/comcast-domain-helper-shuts-down

Jason Livingood (Comcast)


On 11/5/13, 3:38 PM, "Warren Bailey" 
mailto:wbai...@satelliteintelligencegroup.com>>
 wrote:

All,

I've noticed a lot more nxdomain redirects on providers (cox, uverse, tmo, 
etc.) networks lately. How is this being done?? Is it a magic box or some kind 
of subscription service?

Are any of you doing it?

//warren

Re: Reverse DNS RFCs and Recommendations

[Masataka Ohta]

Mark Andrews wrote:

>>> The DHCP reply packet is special as is is broadcasted.
>>
>> What?
>>
>> Rfc3315 is explicit on it:
>>
>> 18.2.8. Transmission of Reply Messages
>>
>> The Reply message MUST be unicast
>> through the interface on which the original message was received.
> 
> While IPv6 is unicast, IPv4 isn't and having a scheme that will work
> for IPv4 as well as IPv6 is useful.

In your draft, you wrote:

   CPE generates DHCPv6 Prefix Delegation [RFC3633] request which

Moreover, even for IPv4, the scheme can (and should) mandate unicast
DHCP reply.

> Also there is NO GUARANTEE that
> the response can't be seen so you design the protocol to work when
> it can be seen.

Your misunderstanding on DHCPv6 is OK, because you also
misunderstand that it were more secure?

Then, as there is NO GUARANTEE that CAs of DNSSEC can't be
compromised, you MUST design the protocol to work when they
can be compromised.

>> And carrying TSIG key in DHCP reply is just secure from the both
>> sides.
>
> Not in the clear it isn't.

Clear text in DHCP reply is just secure when required security
level allows to use DHCP.

Masataka Ohta

Re: Reverse DNS RFCs and Recommendations

[Mark Andrews]

In message <5279f5e1.9030...@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes:
> Mark Andrews wrote:
> 
> >> You misunderstand very basic points on why forward and reverse
> >> DNS checking is useful.
> >>
> >> If an attacker can snoop DHCP reply packet to a victim's CPE, the
> >> attacker can snoop any packet to a victim's server, which is
> >> already bad.
> > 
> > The DHCP reply packet is special as is is broadcasted.
> 
> What?
> 
> Rfc3315 is explicit on it:
> 
>18.2.8. Transmission of Reply Messages
> 
>The Reply message MUST be unicast
>through the interface on which the original message was received.

While IPv6 is unicast, IPv4 isn't and having a scheme that will work
for IPv4 as well as IPv6 is useful.  Also there is NO GUARANTEE that
the response can't be seen so you design the protocol to work when
it can be seen.

> >> That is, Mark's security model is broken only to introduce
> >> obscurity with worse security.
> > 
> > This is a about adding a delegation into the DNS securely so only
> > the machine that the prefix is delegated to and the ISP can update
> > it.  There are a number of reasons to want to do this securely from
> > both the ISP side and the customer side regardless of whether you
> > secure the DNS responses themselves.
> 
> And carrying TSIG key in DHCP reply is just secure from the both sides.

Not in the clear it isn't.
 
>   Masataka Ohta
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org