Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study

[Jim]

On Sun, Jan 3, 2021 at 12:01 AM Mark Foster  wrote:

> And I don't see that opening up a UDP port on every end-user device to
> receive some sort of broadcast (unicast?) is going to be great security.   ...

Yeah:   This is probably best done by either requiring the streaming services to
know where their customers' location is and relay a copy of any pertinent data
to end users through their applications or to web browsers through headers,
Or by having native software included with the OS on internet-connected devices
to query a region-specific URL at a regular interval.

This is much fewer packets if the data can be transferred over the headers of
HTTPS connections which applications on end devices  already make to
various websites.

The UDP port method is inefficient,  at least if meet the requirements
that would seem reasonable for emergency alert distribution on streaming
devices (much the same as for other media...).

1. There should never be extra steps from an end user to "activate"
emergency alerts -
except steps which the device enforces must be done, before any
content can be played.
Notions such as computer users choosing to subscribe to IPAWS fail,
at least, until
some mechanism enforces that they do so.

2. If the device is able to view content, then emergency alerts must
be working.
The function to play alerts should not be able to be disabled and
should resist tampering.
If either an alert has been received,  or emergency alerts would not be able to
be received, then the normal play of content must be interrupted - the ability
to access content should be disabled and be not allowed by the device's
application or operating system until after it can be confirmed that all alerts
have been fully played, or  the error has been corrected.


Problem is that UDP packets to X port could be easily intercepted and dropped by
devices such as firewalls.Merely broadcasting the UDP port during an alert
would not be enough, then;  it would call for a regular broadcast to
this port by
every ISP to every user every few minutes, even when there are no
alerts to relay.

That would seem to be necessary for devices to be able to verify that
alerts would
be working and are not being tampered or interfered with.   Devices would  need
to be designed to verify the latest UDP broadcast has been received
and  Self-Disable
with an error message if too much time has passed with no update
packet on that port;
some type of crypto system would also be needed to verify that messages are
authentic, and have not been forged, replayed, or altered.

The regular UDP broadcast could not be only during an emergency, then,  it
would need to be every few minutes, otherwise the devices  would have no way
of ensuring their ability to receive alerts - that's a massive number
of UDP messages
to consider..


--
-JH

Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study

[Jim]

On Sun, Jan 3, 2021 at 12:02 PM Rich Kulawiec  wrote:
[snip]
> streaming company need to be able to authenticate the alerts from
> all those different agencies.  Those agencies also need to secure  [...]

The agencies would already submit their alerts through IPAWS gateways
managed by FEMA;
otherwise every national satellite & cable provider have a similar challenge.

The feds authenticate agencies and authorize those to use that service
- the streaming
companies only need a way to verify the message originated through
that central authority.

> And then there's another problem, which is that once all those different
> agencies have this facility, they're going to (ab)use it as they see fit.
[snip]

I suppose abuse of authority or excessive use for any alerting system
is bound to be a risk, no matter what.
Not really a technical or network issue at all though.. (People could
petition local elected officials  and/or persuade others within their
district, their neighbors, etc, to vote in new officials  in that
case, etc.)

-- 
-JH

Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study

[Jim]

On Tue, Jan 5, 2021 at 2:50 PM  wrote:

> Could we make the battery just a little more powerful? How much power
> would a bit of circuitry waiting for a "turn on! there's a new message
> coming in!" need?   []

If your  network connectivity, or web browser, or cellular reception
stops working;
people realize very quickly that they aren't getting messages, and
that something is
wrong.  Well,   maybe,  sometimes people break PMTU Discovery by
firewalling off ICMP for "security",  but even more often:

People already ignore testing their smoke detectors.
Emergency radios in smoke detectors would be too hard to test, so basically,
people would not test them every week,  or they would be annoyed by
the weekly test,
and defeat them  -  then when an actual emergency happens,  30% of the
detectors,
don't pick up a thing,  because their local environment and signal
propagation changed,
they're in a signal dead zone, or the nearest NOAA transmitter was 100
miles away,
and there was too much local interference to get a decodable message, anyways.

Emergency receivers are subject to signal, reception, and coverage issues,
even if you can put one in every smoke detector.  They are a neat add-on,
but do not displace the motivation to distribute true emergency messages over
100% of available services from 3rd party communication providers,
including the internet,
cellular networks, broadcast streaming, all services, etc.

Devices used to access streaming services, and web content have a huge
Advantage -  End users receive ordinary content and communications on these
devices every day,  and there is a service provider to continually
monitor services,
so it makes sense to levy the responsibility upon those distribution providers
and network operators - that will make a more reliable result, since
end users don't require extra work
to verify these are actually working, etc.

For Smoke Detector + Emergency receiver..
Probably need to add external power.   Might as well use a separate power
supply and a separate unit.   A smoke detector is microwatts, and a radio
receiver with logic for decoding and processing the analog waveform is more
than a hundred milliwatts.  "Not turning on" - is a sure way to not
receive a signal -
RFI and EM are abundant, and active logic is required to discriminate
a true message.


> etc.
--
-JH

Re: Google uploading your plain text passwords

[Jim]

On Sat, Jun 12, 2021 at 12:33 PM Christopher Morrow
 wrote:
> []
> If the hashed pile of data is 'simply' encrypted with 'gmail/google account 
> password'
> (or that and some token from 'cloud') and decrypted in some form of 
> javascript functions...
> Then only the local browser really knows the content of the hash-file, right?

It seems that in this case, anyone who has any way of knowing the
content of the 'gmail/google account password'  can know the content
of the hash-file.

Can you show that their servers don't also record anybody's account
password or keys derived from it?

If you login to their services,  then you directly send them the
necessary piece of information to create that record, and often,  so
even If they don't retain the browser account password in plaintext...
there are still ways for them to discover what that is:  by adjusting
their login process at a later date to store some extra info. on
successful login,  they would not even need to brute force whatever
hashing scheme they use to protect passwords.

This could be more expedient to them "for Support purposes"  if they
later find many users Ask for help recovering their password vaults
from a forgotten account password -  saving a copy might be more
convenient for their support than not saving a copy of keys.

If they don't store the key today in a way accessible to them, then
it's most likely 1 minor code change to some of their server(s) to mke
and
save a copy of that key derived from the authentication password on
the server side you just auth'd against, at some point

Such change could be made happen at any time, or intermittently, and
since it's code that would reside entirely on the servers, there would
be no possible means on the client of detecting that the server's now
keeping a copy of a login hash:  when you just filled out the login
form in your web browser, etc.

Doesn't matter whether that would be a deliberate update in the future
due to a change in priorities and policies by management,  Or some
rogue/misguided dev trying to solve  a problem, or an actual malicious
actor;  the result is the same -- They would have no obligation to
tell people that they're now saving the key;   the servers can in
theory
possess both the data and the keys used to decrypt it both pieces of
info pass through systems completely administered by the same provider
at some point.

The end user has no visibility and lacks so much as a contract they
would breach by deploying the update.

> NOTE: I have no idea how chrome does it's thing here... but I expect the code 
> is
> visible on chromium.org ? Perhaps even here:
--
-Jim

Re: Can somebody explain these ransomwear attacks?

[Jim]

On Thu, Jun 24, 2021 at 5:41 PM Brandon Svec via NANOG  wrote:
>
> I think a big problem may be that the ransom is actually very cost effective 
> and probably the lowest line item cost in many of these situations where 
> large revenue streams are interrupted and time=money (and maybe also health 
> or life).

Big problem that with organizations' existing Disaster Recovery DR methods --
the time and cost to recovery from any event including downtime will
be some amount.. likely a high one,
and criminals' ransom demands will presumably be set as high a price
as they think they can get --
but still orders of magnitudes less than cost to recover / repair /
restore, and the downtime may be less.

The  ransom price becomes the perceived cost of paying from the
perspective of the
organizations faced with the decision,  But the actual cost to the
whole world of them paying
a ransom is much higher and will be borne by others (And/or themselves
if they are unlucky)
in the future, when their having paid the criminals encourages and
causes more and more of that nefarious activity.

I would call that a regulatory issue regarding commerce and payments
not able to be addressed by technology.

No matter how much companies can improve your DR process to cost less
for a recovery
and take less time -- a recovery is bound to still involve some
downtime and cost a large enough amount  where it
will then be possible for motivated criminals to come up with a
dollars cost improvement for a ransom that will be less than it.

I do wonder for a moment.. about companies paying ransoms: Do they
somehow manage to get
the crooks' W-9 and verify their identity, as required when an
organization makes a payment to
any 3rd party -- or do those paying ransoms somehow circumvent the
mandatory tax reporting and
witholdings,  B/c it seems like making a payment to an Unnamed /
unidentified / unverifiable party
ought to be a crime  or make the payor be considered an accomplice in
the crooks' evasion of the taxing authority?

I always think.. have the governments impose penalties, eg.
"If you make a payment for a ransom, then a penalty of  $10k plus
1% the ransom will be due."
/ Have it be a more-severely penalized crime to send any digital
payment for a transaction above X say $1000 without the Proof of
Identity
and Physical location of all Payees -- make sure it gets enforced
strictly against anyone paying a ransom.
Make the ransoms not payable without larger repurcussions, and perhaps
the crooks will have to find a new profession.

>
> The original thought that it should be handled like standard DR and tighten 
> up security may apply to very small businesses though where they could afford 
> to try to ignore the ransom request and rebuild more securely hoping the 
> criminals will move on and not come back for revenge.
>
--
-Jim

Re: shadowserver.org

[Jim]

On Mon, Jun 28, 2021 at 9:22 AM Tom Beecher  wrote:
> Shadowserver is constantly doing all kinds of port scanning and penetration 
> attempts globally, have been for many years.

They conduct probes and queries that are basically routine
communications against IP Address Port pairs that have been routed on
the public internet. There is nothing I have seen / No evidence of
shadowserver specifcally ever conducting a penetration attempt  or
other actual abuse,  such as attempting to gain access to computers or
data beyond reports on publicly-accessible services would be, but
please do show more details if that could be the case now..

There are many parties who do scans and send basic queries for reasons
that have nothing to do with penetrating or attempting to penetrate
anything -- those are just queries.  For example DNS query to port 53,
in order to detect hosts that have a level of  service open to the
public like Open Resolvers, which service does not meet current
standard, or is a subset of hosts presenting a high risk to other
networks,  so that info. can be communicated to ISPs and upstream
providers to mitigate.

>
> On a residential connection as you describe, have something in place that 
> drops anything from them, and move on with your day.
--
-Jim

Re: shadowserver.org

[Jim]

On Mon, Jun 28, 2021 at 12:04 PM Jean St-Laurent  wrote:
> What is the difference between shodan.io and shadowserver.org ?

In what regard?  Both of those conduct frequent scans of the IPv4
internet.  Neither of them attacks nor penetrates.   The former may be
a more tailored scan.

Shodan's a for-profit site that provides access to general data from
their scans about any hosts/networks on the internet to anybody who
wants to search their data and pays for a subscription.

Shadowserver's a non-profit.. cost $0 for the ISP to subscribe to
their reports, that generates reports on certain issues  specifically
against botnets, malware, DDoS risks; they distribute to the IP block
owners on need-to-know.

> Jean
-- 
-Jim

Re: Aptum refuses to SWIP

[Jim]

On Fri, May 5, 2023 at 12:09 PM Blake Hudson  wrote:

>
> On 5/4/2023 9:09 PM, Forrest Christian (List Account) wrote:
>
> I can't speak for aptum, but I'm curious as to why this is important to
> you?
>
> > SWIP'ing or delegating address space is a requirement of the contract
> signed with ARIN when
>

They can SWIP or Publish the information in "a directory services system
which meets the standards set forth in section 3.2."  ISPs are Required to
publish each individual network delegation of a /29 or more addresses
Identifying the holder,
other than they can Redact the personal information for
individual residential customers.

So an ISP Don't have to SWIP as long as they do the second thing,  But
Either way each individual customer network
larger than the size threshold and their provided  contacts are to appear
in WHOIS.

This is important in order to
provide accurate NOC / Technical and Abuse contact to the community for the
purposes Of  validating legitimate
technical contacts for a variety of reasons,  contacting users about
connectivity issues,  and being able to
submit abuse reports expeditiously to All Involved contacts (Abuse reports
and technical issues are not to be sent
Solely to a network's upstream provider).

If the info. is not published then they are not fulfilling their
obligations and expected conduct as a network service provider
(they have not subdelegated those numbers and retain them for their own
use).

--
-J

Re: New addresses for b.root-servers.net

[Jim]

On Thu, Jun 1, 2023 at 5:59 PM William Herrin  wrote:

A server generation is about 3 years before it's obsolete and is
> generally replaced. I suggest making the old address operable for two .
> generations (6 years) and black-holed for another generation (3 more  
>

As you mention.. there is No TTL for the root hints.  The TTL is Infinite.
And not
all users will be retired after 3 years... there are DNS resolvers online
running
10-year old code and there are DNS resolvers on the internet that may not
see a roots hint
update in the next 10 years.It is unlikely that there is any practical
way of giving notice
to the operators of such servers.

Therefore, I would suggest IP Addresses that ever appeared in the official
root hints
should be reserved permanently and exclusively for official root service,
then blackholed indefinitely once service
is not in operation anymore to prevent any DNS service other than an
official root server appearing at
that IP at any point in time in the future  no matter how many years have
elapsed (Infinite TTL).

A major concern would be if the IP address were eventually re-assigned to
something else that
ended up reporting false answers due to a malicious or misconfigured DNS
service.

DNS resolvers can handle no answer by trying other servers,  but
a false answer from an unauthorized and malicious root service being
received by non-validating
resolvers would be fairly certain to be capable of causing total failure in
the resolver;
while an IP address being offline would more likely only cause impairment
or delays.

It's understandable if some root service IP addresses stop providing
service years after
the end of service, and resolvers should still be able to function at some
level with
reduced resiliency and increased errors  if only a small number have
changed.


> Regards,
> Bill Herrin
>
--
-JH

Re: TACACS+ server recommendations?

[Jim]

On Wed, Sep 20, 2023 at 11:16 AM Mike Lewinski via NANOG 
wrote:

> > https://www.shrubbery.net/tac_plus/
> That tac_plus has python 2 dependencies and so has been removed from
> Debian packages. That's not surprising given the last update was 2015 and
> Python 2 was EOL in 2020: https://www.python.org/doc/sunset-python-2/

Currently I favor this one which is still being actively developed:
> https://www.pro-bono-publico.de/projects/tac_plus.html


Yes.   Well, on the plus side the TACACS protocol has not really changed in
30 years,
Even the 2015 code could work provided you can compile its dependencies
from sources, right...

On the downside, for the command authorization use:
TACACS+ provides little protection for messages between client and server;

The protocol's MD5 crypto is so weak that routers using TACACS+ for
authentication
might as well just be piping over user credentials in the clear: it's
barely any better.

Router operating systems still typically use only passwords with
SSH, then those devices send the passwords over that insecure channel.  I
have yet to
see much in terms of routers capable to Tacacs+ Authorize  users based on
users'
openSSH certificate, Public key id,  or  ed2559-sk security key id, etc.

In short..  unless you got a VPN or a dedicated secure link from every
single device to
its Tacacs server or an Experimental   implementation of TACACS+ over  TLS:
I would suggest consider Using tools or scripts to distribute users and
Authorizing configurations to
devices as local authorization through secure protocols as favorable to
those network authentication systems
that transmit sensitive decisions and user data across the network using
Insecure protocols.

-- 
-Jim

Re: TACACS+ server recommendations?

[Jim]

On Thu, Sep 21, 2023 at 4:40 AM Simon Leinen  wrote:

>
> Ahem... Cisco supports SSH authentication using *X.509* certificates.
> Unfortunately this is not compatible with OpenSSH (the dominant SSH
>

It's not a great solution, but it is certainly a solution.
The feature exists for some routers/switch models running certain
licenses/images...
an existing 200 NE network is not likely to have the feature 100% available
by accident, though.

On the other hand:  the strategy of using local auth on devices and having
a few local users
with specific privilege levels,  and centralized systems that manage the
ones creds for all
normal day-to-day usage: Storage and frequent automatic rotation of
passwords, and
when an operator needs to login:  the central system authorize a privileged
User to access,

Either "check out" a device using AAA to decide who can check out which
devices,
Or users run their SSH sessions through centralized connection managers
(Acting as a man-in-the-middle authenticating
to devices using its own credentials.  Authorizing user commands proxied
through
the server)  -   Allows AAA  and command authorization to be performed by
the central server.

My understanding is a good number of password manager products exists which
will handle that,
and then the only AAA  which  network devices need to be concerned about
for Authentication and
Authorization is  Basic password auth,  which all equipment supports.   And
the security problems
don't arise so much for using the TACACS+ / Tac_plus service Solely for
Accounting
(in addition to basic remote syslog).

client implementation we use), which only supports *OpenSSH*
> certificates.
>

--
-Jim

Re: DNS hijack?

[Jim]

On Fri, Nov 12, 2021 at 1:29 PM Stephane Bortzmeyer  wrote:
> On Thu, Nov 11, 2021 at 09:44:04PM +, [..]
> It depends on where you are (from my resolver, I get
> 64.130.197.11). This is because the name voyager.viser.net is not
> stable yet. Depending on your resolver, it points to 64.130.200.16 -
> which seems to give correct answers - or to 208.91.197.132 - which
> replies even for nonexisting domain names.
[..]

So yes, then.. A DNS Hijack by NetSol redirecting the hostname on an expired SLD
related to one of the individual nameserver hosts to a
faulty/non-compliant nameserver
of NetSol's that then publishes bogus RRs for domains that registrar
have no authority over.

That means instead of the 1 nameserver failing; the entire domain
breaks, even if there are multiple nameservers listed, and only 1 had
been accidentally allowed to expire.

DNSSEC would help here.   NetSol's rogue nameserver wouldn't be able to produce
the signed zone if validation were required.

-- 
-JH

Re: DNS hijack?

[Jim]

On Fri, Nov 12, 2021 at 6:38 PM Robert L Mathews  wrote:

> I didn't see the page, but for what it's worth, this is governed by this
> ICANN policy:> https://www.icann.org/resources/pages/errp-2013-02-28-en

It is common that registrars repoint nameservers and redirect web traffic when a
domain's renewal has not been paid for (during 45-day grace period
provided by the registry),
probably more registrars do that than not.

The issue here is not with the expired domain, thus not addressed by
that ICANN policy...

The ICANN policy addresses interrupting the resolution path and
redirecting Web traffic
for expiring domains; there's nothing about other services on those
domains such as
DNS when the expired domain has a backup nameserver host of a
non-expired domain.

In this case, interrupting the resolution path would be fine  (In case
the non-expired domain
have other nameservers),

But the redirection causes DNS instability and failures for domains
that are not expired, even if those domains have other nameservers,
and the non-expired domains get redirected to a web page falsely stating
that they are expired.

--
-JH

Re: WKBI #586, Redploying most of 127/8 as unicast public

[Jim]

On Thu, Nov 18, 2021 at 11:05 AM John R. Levine  wrote:
..> The IETF is not the Network Police, and all IETF standards are entirely
> voluntary.

Yes, however the IETF standards can be an obstacle -- if they are, then
it is reasonable to adjust that which might impede a future useful development:
regardless of the fact that other obstacles may exist and it may be predicted
to be infeasible in the end.  The estimation that effort to update
software will not be
worthwhile much later (10 years from now)  cannot be made with enough
confidence;
the other efforts that need to happen is not justification to keep the
standard from changing so
that new/updated software coming out in the near future have a chance to
avoid making making future efforts to reclaim class E or a portion of
127/8 any harder than
they already are today.

The improbability or cost involved in getting software updated should
not impede updating a standard --  Just like the low rate of IPv6
deployment and the
estimation that IPv6 Never manage to fully and totally replace IPv4
should Not prevent
further development of IPv6  nor  giving up on IPv6, etc.

Both IPv4 and IPv6 are important standards that should continue to be
maintained.

> Nothing is keeping you from persuading people to change their software to
> treat class E addresses as routable other than the detail that the idea is

The standard could keep you from persuading people - if the standard
says that class E is something else, then the chance of it ever getting close
to be globally usable is about zero .

If the Standards are updated to say that it is globally routable,
Then the chance
of it ever becoming globally routable is still close to zero, at least
for a long period of time,
BUT at least it is improved,   even the small improvement that can
come from fewer new software programs
outright blocking it justifies updating the standard,  there is no
real downsideother than the time and effort'
to actually update the standards..


Adjusting 127/8  is the same way.  It seem pretty obvious this should be done..
make the reservation 127.0.0.0/24, or /32, even, and declare the full
of 127.0.0.0/8 as
Unicast reserved.  This does not immediately change any software or
operating systems nor
affect anyone's network, since the range in question is non-routable
it has only to do
with individual systems using IPv4 internally and privately,  not
related to the internet
or any IP networks to begin with  (unless some router internally have
a large swath
of 127/8 for internal system services on its main routing table) -  anyway,
System applications can continue using 127/8
internally on local loopback interfaces for local IPC to the heart's content,
Until such time as  Operating Systems choose to make (or choose not to
make) changes
to their own system networking functions and network libraries.

Or perhaps they would consider a configuration option such as
   -  "use one of the  /8s from Class E  for loopback, in Lieu of  127/8."


As a practical matter on modern OSes:  "127.*" seem more of a convenience;  You
can run network-based apps privately and use standard network tools such
as "telnet 127.0.0.0"  to test protocols over your local Loopback
'devices'  without needing
to  give an interface such as "ssh -B lo0 127.0.0.0"  --

If that's not the scenario  (Not a  need to access Local applications
using a common network utilities such
as 'ssh' or 'web browser'),   Then there are ample alternatives
for example:  "Open connection to file /opt/var/run/mysql.sock"
So, uh you only really have reason to use by design 127.0.0.0  if your
software wish to be used over a network.

If it's not such a "standard" client/server program being tested locally,
you can give an interface within the design of your local apps and use
Loopback networks all day without any 127 addresses..  if your OS
make you specify an interface instead of routing Loopback device
traffic,  then you could
potentially be allowed to accept and use Any IP in all of the IPv4
space on the Loopback
as part of a  separate and distinct private "network", so you could
Re-Use all the RFC1918
IP space for your Loopback IP space without conflicting with other
RFC1918 address usage.

You need only 1 IP address to talk to your local system -  Maybe you
run something such as Docker container host, I guess, then a whole /16
seem Ok...


> R's,
> John
--
-JH

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Jim]

On Thu, Nov 18, 2021 at 8:24 PM David Conrad  wrote:
>
...
> Some (not me) might argue it could (further) hamper IPv6 deployment by 
> diverting limited resources.

It may help IPv6 deployment if more V4 addresses are eventually
released and allocated
Assuming the RIRs would ultimately like to provision the usage of
addresses within their own policies
that the new address releases are exclusively for  'IPv6 Transition
Tech.',  such as CGN NAT addresses,
And make the proviso that new Allocations should be revoked/reduced on
the basis of Non-Use alone  if found not
being used highly-efficiently --- reducing the cost of  "New" V4
addresses  but Restricting who can get the
allocations and for what..  May make the scarcity "Fairer"  between
Older existing Network Service Providers
versus  Brand new Network Service Providers  who did not get to start
with pre-assigned IPv4,
 thus Helping V6 deployment.

An important thing to hamper IPv6 deployment is bound to
be newfound difficulty getting IPv4 numbers, and there are a large number of
hosting and access network service providers pre-distributed IPv4,  so
currently IPv4 is
scarce enough to discourage new providers deploying IPv6 (because it
will discourage
new providers starting and making any networks at all), But  because of existing
assignments, IPv4 is not scarce enough for existing providers to feel
immediate pressure or need/desire to provide end to end IPv6 connectivity ---
not when they can potentially pay up for more IPv4 and gobble up other
NSPs through
acquisitions.

IPv4 numbers are required in order for network service providers to
deploy IPv6 to
subscribers, and for those subscribers to have connectivity to the
majority of networks
--- If you cannot get the IPv4, then more likely that new network
service provider
does not get created and offer service in the first place.   Alternatively
new service providers find a costly source of some IPv4 numbers and pay up
only to result in eventual necessity of deploying IPv6 services at a
higher-price:
it places existing providers with legacy IPv4 assignments at competitive
advantage, and gives existing providers reason to decline or delay fully
deploying IPv6 end-to-end.


Even if you want to give your Subscribers IPv6 only and utilize no V4
addresses for them
like some large mobile providers;  you still end up needing a
technology such as 464XLAT
or CGN in the end,  and you are still going to require a substantial
sum of IPv4 addresses
in order to do it.

>
> > What will it *cost* to upgrade
> > every node on the Internet?  And *how long* might it take?

You need an upgrade timeframe for "cost to upgrade" to make sense.  It
is unlikely any node will proceed forever without any upgrades - After
a sufficient number of years, or decades have passed;  You will get to
a point where every node, or almost every node had to have new
software or replacement hardware for multiple reasons at some point,
once a new version of Windows fixes your issue,  your one IPv4 tweak
is 0.001% of the cost or less of the new version release..For
example,  Windows XP devices are almost nowhere to be seen anymore,
less than 1%   -   If the time frame is about 5 years,  then by that
time most server/personal computers ought to have been replaced, or at
least running a newer major OS version.

The upgrade have a cost, but at that point there are numerous reasons
it is required, and the upgrade cost is subsumed by the cost required
just to maintain any system  (With 5+ years, the upgrade cost goes
down to almost zero compared to the cumulative Annual
upkeep/depreciation).

Of course upgrades that must be done immediately, or within a short
schedule are more expensive.

--
-JH

Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[Jim]

On Sat, Nov 20, 2021 at 1:02 PM Michael Thomas  wrote:
> On 11/20/21 10:44 AM, Chris Adams wrote:

> that it needs 400M addresses. If you wanted to reclaim ipv4 addresses it
> seems that class D and class E would be a much better target than loopback.
> Mike, not that I have any stake in this

400M addresses may be excessive,  but not so much the Low-hanging fruit
you seemed to suggest.  May be worth the consideration to reduce,
but need to see your draft standard first,  about what exactly you propose to
reclaim from class D..

Unlike class E and 127/8,  there are many protocols and applications that
communicate between separate devices on a network over class D in a
non-unicast manner to contend with that utilize either official MC assignments,
or Private/org-specific assignments from available class D space

 - Multicast/broadcast addresses used by many control systems such as
routing protocols (VRRP),
camera systems / physical security,  etc.

--
-JH

Re: This DNS over HTTP thing

[Jim]

On Mon, Oct 7, 2019 at 11:44 AM Kevin McCormick  wrote:
>
> If the DNS request comes from an IP in matching a CIDR network address in the 
> ULS record, then the server would respond with an error message telling the 
> application to use the configured local DNS server.

All if this is ultimately falsifiable by a malicious or rogue DNS operator.

My suggestion would be ultimately that DNS Clients implement DNSSEC
validation themself to avoid tampering by a malicious client on their network
for phishing purposes or a malicious recursive DNS Resolver server ---  Such
a DNS proxy service in a home router corrupted by malware that
modifies DNS resposes
for an attacker,  or  those rogue DNS servers of ISPs that typically sometimes
replace NXDOMAIN replies with A records attempting to collect typo queries
for advertising or that redirect A records to other hosts designed to intercept
and monitor or proxy traffic with advertisements inserted.

A secure administrative selection of local DNS server could be supported by
allowing a TXT record to be placed in the reverse DNS zone for the IP address
which is the IP address configured on the client's IP network
interface alongside
PTR records.

The client software would then be required to perform a DNSSEC
signature check to
ensure that the reverse DNS zone is signed and has the proper chain of signed
DS records ultimately coming from the IP6.ARPA  or IN-ADDR.ARPA zone.

*
Clients using RFC1918 IP addresses would not be able to support this;  Because,
there is no way of  establishing WHO is authorized to sign locally on
behalf of the "operator" of a RFC1918 or link-local IP address...

The latter seems more like a system administration problem however --

The DHCP software running on a client ought to have some way of
indicating whether the network being connected to is  Secure and
"Managed" by the same entity that owns and configures the client device:

I.E.  Same company manages the LAN and the entire path up to recursive
DNS servers are secure,Or whether the PC is owned and managed by
different entities --  such as a  mobile PC user connected to someone
else's network,
or a Home user connected to their own ISP,  and the network is, therefore,
untrusted.

(Untrusted in the sense that DNS Servers are controlled by
a 3rd party who is not the owner or operator of the personal computer
or client device which is connecting for the supposed purpose of
accessing the public internet  --- therefore no legitimate authority
exists for having clients tolerate tampering with private traffic
between that device and another internet host, content in DNS or other
IP traffic content, and so on)

> Thoughts?
> Thank you,
> Kevin McCormick
--
-JH

Re: FCC Takes Steps to Enforce Quality Standards for Rural Broadband

[Jim]

On Thu, Oct 31, 2019 at 1:08 PM Jeff Shultz  wrote:
>[snip]
> What has most people (from anecdotal observation) concerned is that we
> are usually more than one or two carriers out from an IXP where the
> speed test server will be, and don't have a lot of influence on paths
> and carriers that we aren't directly connected with.

It sounds like there would be some test method concerns there by
having merely one performance-testing server.

But the performance of "broadband service"  is really end to end;
the choice of direct carrier,  their routing policies, and indirect carriers,
is still an integral part of the service that should be measured ---
the best last mile connection possible has no value if the provider is
allowed to mess that up by undersizing peering or backhaul, whether
directly,  or indirectly through carriers which end-to-end traffic depends upon.

Seems like a testing method might have a plethora of speed testing servers
and include HTTPS bandwidth tests through websites fronted by numerous
CDN nodes  which are by design indistinguishable from regular traffic.

Given enough varying remote test locations and a large enough number
of samples over time,  and providers prevented from being able to
distinguish what traffic or users might be test traffic or test users and
which users or traffic might be normal traffic;   It seems like they ought
be able to formulate an automatic analysis of the data  that will limit the
affect of  "noise"  such as one-off  suboptimal routing to some destinations,
involving one IXP, etc.

> --
> Jeff Shultz
--
-JH

RE: AOL Postmaster?

[Jim Popovitch]

On Fri, 2007-04-13 at 14:39 -0400, David Hubbard wrote:
> I'm still getting feedback on netblocks we haven't been
> associated with in several years and I've tried about
> 20 times to get them to stop it but cannot.  If you call
> they just tell you to email, if you email you get nowhere.

I've had that experience in the past too.  Even today, despite periodic
emails to them, I still get daily "Current IP Address(es) Listed with
AOL" emails from [EMAIL PROTECTED], yet the IP addresses are an
incomplete list of IPs that they have been provided and that they have
accepted.  I can delete the daily emails, but to me it is symptomatic of
underlying problems with their FBL system.

If anyone from AOL wants to debug this... here are some of your
Message-id's:

[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

If you can figure out why you are sending me daily emails, I certainly
would appreciate it.  Previous calls and emails have been fruitless, but
not frustrating.

-Jim P.

RE: Question on 7.0.0.0/8

[Jim Popovitch]

On Sun, 2007-04-15 at 22:58 +0100, [EMAIL PROTECTED] wrote:
> As a result, most people consider William Leibzon and the Bogon project
> to be, collectively, the authoritative source for information on whose
> IP address that is. That's because William and the Bogon project, act
> authoritative, and take some pains to provide comprehensive data. 

I truly want to believe that, and I do appreciate the effort that Willam
and Elan put into this.  That said, I do near-daily diffs between
changes made to
http://completewhois.com/bogons/data/data-bgp-announced/announced_bogon-cidr-all.txt

Here are today's deletions from Friday's list, do bogons really change
that frequently?

 76.0.0.0/13
 76.0.0.0/19
 133.1.0.0/16
 133.2.0.0/16
 133.3.0.0/16
 133.4.0.0/16
 133.5.0.0/16
 133.6.0.0/16
 133.7.0.0/16
 133.8.0.0/16
 133.9.0.0/16
 133.10.0.0/16
 133.11.0.0/16
 133.12.0.0/16
 133.13.0.0/16
 133.13.0.0/17
 133.14.0.0/16
 133.15.0.0/16
 133.16.0.0/16
 133.17.0.0/16
 133.18.0.0/16
 133.19.0.0/16
 133.20.0.0/16
 133.21.0.0/16
 133.23.0.0/16
 133.24.0.0/16
 133.25.0.0/16
 133.26.0.0/16
 133.27.0.0/16
 133.28.0.0/16
 133.29.0.0/16
 133.30.0.0/16
 133.31.0.0/16
 133.33.0.0/16
 133.34.0.0/16
 133.35.0.0/16
 133.36.0.0/16
 133.37.0.0/16
 133.38.0.0/16
 133.39.0.0/16
 133.40.0.0/16
 133.41.0.0/16
 133.42.0.0/16
 133.43.0.0/16
 133.44.0.0/16
 133.45.0.0/16
 133.46.0.0/16
 133.47.0.0/16
 133.48.0.0/16
 133.49.0.0/16
 133.50.0.0/16
 133.51.0.0/16
 133.52.0.0/16
 133.52.0.0/17
 133.53.0.0/16
 133.54.0.0/16
 133.55.0.0/16
 133.56.0.0/16
 133.57.0.0/16
 133.58.0.0/16
 133.60.0.0/16
 133.62.0.0/16
 133.63.0.0/16
 133.64.0.0/16
 133.65.0.0/16
 133.66.0.0/16
 133.67.0.0/16
 133.68.0.0/16
 133.69.0.0/16
 133.70.0.0/16
 133.71.0.0/16
 133.72.0.0/16
 133.73.0.0/16
 133.74.0.0/16
 133.75.0.0/16
 133.77.0.0/16
 133.78.0.0/16
 133.79.0.0/16
 133.80.0.0/16
 133.82.0.0/16
 133.83.0.0/16
 133.85.0.0/16
 133.86.0.0/16
 133.87.0.0/16
 133.88.0.0/16
 133.89.0.0/16
 133.91.0.0/16
 133.92.0.0/16
 133.94.0.0/16
 133.95.0.0/16
 133.96.0.0/16
 133.97.0.0/16
 133.98.0.0/16
 133.99.0.0/16
 133.100.0.0/16
 133.101.0.0/16
 133.102.0.0/16
 133.103.0.0/16
 133.104.0.0/16
 133.105.0.0/16
 133.106.0.0/16
 133.109.0.0/16
 133.111.0.0/16
 133.121.0.0/16
 133.125.0.0/17
 133.127.0.0/16
 133.130.0.0/16
 133.137.0.0/16
 133.138.0.0/16
 133.140.0.0/16
 133.145.0.0/16
 133.146.0.0/16
 133.148.0.0/16
 133.149.0.0/16
 133.152.0.0/16
 133.153.0.0/16
 133.158.0.0/16
 133.163.0.0/16
 133.164.0.0/16
 133.169.0.0/16
 133.170.0.0/16
 133.173.0.0/16
 133.176.0.0/16
 133.186.0.0/16
 133.187.0.0/16
 133.188.0.0/16
 133.192.0.0/16
 133.194.0.0/16
 133.205.0.0/16
 133.215.0.0/16
 133.216.0.0/16
 133.217.0.0/16
 133.218.0.0/16
 133.220.0.0/16
 133.221.0.0/16
 133.225.0.0/16
 133.226.0.0/16
 133.232.0.0/16
 133.235.0.0/16
 133.236.0.0/16
 133.237.0.0/16
 133.238.0.0/16
 133.240.0.0/16
 133.243.0.0/16
 133.245.0.0/16
 133.249.0.0/16
 133.250.0.0/16
 133.253.0.0/16
 133.254.0.0/16
 193.33.178.0/23

I'm just trying to get a complete (not constantly changing) list of
bogons.

-Jim P.

Re: Advice requested

[Jim Popovitch]

On Tue, 2007-05-29 at 12:53 -0400, George Imburgia wrote:
> On Tue, 29 May 2007, Matthew Black wrote:
> 
> > What would you do if a major US computer security firm
> > attempted to hack your site's servers and networks?
> > Would you tell the company or let their experts figure
> > it out?
> 
> I'd hold a very public discussion on the matter.

Just a few words of caution 

First make sure that it is a hack, and not just a ping or SMTP test
because they are trying to deliver you email.  I did ask for a
definitive of what the OP meant by hack, but haven't seen anything yet.

Secondly, make sure that no one else in your company authorized this.  A
lot of companies do pay outside agencies to test their security.
Security Audits are notorious for being requested by the corporate
Financial personnel, and those are the same folks that the networking
dept communicates the least with (IMHO).

Finally, is it possible that the "hack" was planned behavior or a well
intended mistake?  Years ago, others at $DAYJOB, received customer
provided configuration files to try an emulate a customer problem.  All
sorts of interesting traffic left our network and hit the customers,
after all their configs had all their IPs listed.  The customer's
security department (left hand) called the FBI simply because they
didn't know what their own network department (right hand) was asking
$DAYJOB to do.

-Jim P.

Security gain from NAT (was: Re: Cool IPv6 Stuff)

[Jim Shankland]

Owen DeLong <[EMAIL PROTECTED]> writes:
> There's no security gain from not having real IPs on machines.
> Any belief that there is results from a lack of understanding.

This is one of those assertions that gets repeated so often people
are liable to start believing it's true :-).

*No* security gain?  No protection against port scans from Bucharest?
No protection for a machine that is used in practice only on the
local, office LAN?  Or to access a single, corporate Web site?

Shall I do the experiment again where I set up a Linux box
at an RFC1918 address, behind a NAT device, publish the root
password of the Linux box and its RFC1918 address, and invite
all comers to prove me wrong by showing evidence that they've
successfully logged into the Linux box?  When I last did this,
I got a handful of emails, some quite snide, suggesting I was
some combination of ignorant, stupid, and reckless; the Linux
box for some reason remained unmolested.

Jim Shankland

Security gain from NAT (was: Re: Cool IPv6 Stuff)

[Jim Shankland]

[EMAIL PROTECTED] writes:

> On Mon, 04 Jun 2007 11:32:39 PDT, Jim Shankland said:
> > *No* security gain?  No protection against port scans from Bucharest?
> > No protection for a machine that is used in practice only on the
> > local, office LAN?  Or to access a single, corporate Web site?
> 
> Nope. Zip. Zero. Ziltch.  Nothing over and above what a good properly
> configured stateful *non*-NAT firewall should be doing for you already.

Thanks for the clarification, Owen and Valdis.  We are, of course,
100% in agreement that it is stateful inspection that provides
(a measure of) security, and that stateful inspection can be had
without NAT.

But NAT *requires* stateful inspection; and the many-to-one, port
translating NAT in common use all but requires affirmative steps
to be taken to relay inbound connections to a designated, internal
host -- the default ends up being to drop them.  All this can be
done without NAT, but with NAT you get it "for free".

I can't pass over Valdis's statement that a "good properly configured
stateful firewall should be doing [this] already" without noting
that on today's Internet, the gap between "should" and "is" is
often large.

If what you meant to say is that NAT provides no security benefits
that can't also be provided by other means, then I completely
agree.

Jim Shankland

Re: FBI tells the public to call their ISP for help

[Jim Popovitch]

On Thu, 2007-06-14 at 07:41 -0700, Owen DeLong wrote:
> Wouldn't it be more appropriate if the FBI told people the phone  
> number to Micr0$0ft?

It would lighten the load on the ISPs, but would it really achieve
anything worthwhile? 

-Jim P.

RE: Yahoo/Verizon issues?

[Jim Popovitch]

I saw similar up until about 5 mins ago.  All seems well now.

-Jim P.

On Fri, 2007-07-06 at 10:16 -0400, Mike Callahan wrote:
> We have started receiving some reports related to yahoo as well.  We're 
> seeing some latency it would appear at the Level3 hand-off to yahoo.
> 
>  13 *   70 ms77 ms  ge-0-3-0-69.bbr2.sanjose1.level3.net 
> [4.68.18.2]
>  
>  14 *   78 ms71 ms  so-14-0.hsa4.sanjose1.level3.net 
> [4.68.114.158]
>  
>  15   487 ms   449 ms   459 ms  hanaro.hsa4.level3.net [4.79.60.22]
>  16 *** Request timed out.
>  17 *** Request timed out.
>  18 *  586 ms * te-8-1.bas-a2.sp1.yahoo.com [209.131.32.19]
>  19 *  570 ms * f1.www.vip.sp1.yahoo.com [209.131.36.158]
>  20 **  591 ms  f1.www.vip.sp1.yahoo.com [209.131.36.158]
>  
> Trace complete.
> 
> Mike
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
> Marcus H. Sachs
> Sent: Friday, July 06, 2007 10:05 AM
> To: 'Nanog'
> Cc: [EMAIL PROTECTED]
> Subject: Yahoo/Verizon issues?
> 
> 
> 
> We (Internet Storm Center) are getting scattered reports of Yahoo being
> down, and problems with Verizon's networks.  Anybody else seeing this?
> 
> Marc
> 
> 
> --
> Marc Sachs
> SANS ISC
> 
> {The [EMAIL PROTECTED] email address is an alias for a mailing list of
> approximately 35 volunteer incident handlers. You may receive responses from
> other individuals on that list. Please include the [EMAIL PROTECTED] address
> in any replies so that everyone is kept "in the loop".}
> 

Re: San Francisco Power Outage

[Jim Popovitch]

On Tue, 2007-07-24 at 19:57 -0400, Patrick Giagnocavo wrote:
> 
> On Jul 24, 2007, at 6:54 PM, Seth Mattinen wrote:
> >
> > I have a question: does anyone seriously accept "oh, power trouble"  
> > as a reason your servers went offline? Where's the generators? UPS?  
> > Testing said combination of UPS and generators? What if it was  
> > important? I honestly find it hard to believe anyone runs a  
> > facility like that and people actually *pay* for it.
> >
> 
> Sad that the little Telcove DC here in Lancaster, PA, that Level3  
> bought a few months ago, has weekly full-on generator tests where  
> 100% of the load is transferred to the generator, while apparently  
> large DCs that are charging premium rates, do not.

Perhaps they do.  Wouldn't have mattered in this case if the
big-red-button rumor is real.  ;-)

-Jim P.

Re: DNS not working

[Jim Popovitch]

On Fri, 2007-08-17 at 12:12 -0400, Tuc at T-B-O-H.NET wrote:
>   I'm also shocked someone would actually advocate this. I'm 
> sure Google wouldn't be too happy to find out about it.

This begs the question... why is the OP trying to do this with DNS
instead of a caching proxy?

-Jim P.


(no legal disclaimer here)

Re: OT: Remebering Abha Ahuja - 6 years

[Jim Popovitch]

On Sat, 2007-10-20 at 18:01 -0400, Patrick W. Gilmore wrote:
> Sorry for the OT post, but it has been 6 years since Abha passed.
> 
> I'm sure there's lots more to say, but I don' think I can say it.
> 
> Rest in peace, Abha.  You know how much we miss you.

I never met Abha, but I did read the memorial and other links 
located here: http://www.nanog.org/abha.html , and I can see how a lot
of folks had a deep appreciation for her.

If there can be weeks long discussions on 240/4 or ipv6, why not at
least a day or two of remembrances from everyone on what Abha did for
the community as well as ways she might have helped you?

-Jim P.

Re: Cisco outage

[Jim Popovitch]

On Tue, 2007-11-27 at 01:17 -0500, [EMAIL PROTECTED] wrote:
> On Mon, 26 Nov 2007 17:06:38 CST, "J. Oquendo" said:
> > 
> > In re: previous post
> > 
> > http://www.news.com/8301-10784_3-9823196-7.html
> > 
> > So much for self healing networks eh
> 
> Given that according to the link you provide, at some points, the *main* page
> was working, but other pages on the same server were broken, that tends to
> say "webserver screwup" rather than a networking issue. So the problem is
> probably (one or more of) Windows/Linux/Unix/IBM/Dell/Sun/etc, none of which
> are *network* kit by any reasonable stretch of the imagination.
> 
> Unless somewhere along the line, IOS grew an Apache module?

Cisco (Distributed|Local)Director is close to *network* kit.  ;-)


-Jim P.

Re: Cox clamping VPN traffic?

[Jim Popovitch]

On Jan 25, 2008 12:17 PM, Tomas L. Byrnes <[EMAIL PROTECTED]> wrote:
>
>
> I've got a local peer with Cox for VPN users to co-lo. A VPN connection that
> otherwise shows no issues just had their file transfer rate during a large
> file transfer over the VPN go from 10Mbps to 43kbps, and stay there. This
> isn't transit, it's local peering.

I see the *exact* same problem with Comcast at home.  I get about 30
seconds of the 6.6Mbps provisioned rate then the drop kicks in and
down to 43kbps it goes.  In talking with Comcast engineers privately,
I've learned that the "provisioned" rates should no longer be
considered as sustainable, only initial.   Now I don't normally need a
sustained up/down rate, but it has come in handy in the past when
up/down-loading backups or ISOs... but I guess those days are behind
us as the large providers have started re-interpreting the definition
of "provisioned", or to be more accurate they have implemented a TTL
on it.  That said, I do see their point of view wrt PTP, esp torrent
traffic, and their desire to limit it's impact on their networks
but it does boil my blood when *I* need to use "my" bandwidth for
legitimate purposes only to find myself throttled. :-)   Part of me
wonders if this isn't an effort to push "business" class services.

-Jim P.

Re: Worst Offenders/Active Attackers blacklists

[Jim Popovitch]

On Jan 29, 2008 12:58 AM, Patrick W. Gilmore <[EMAIL PROTECTED]> wrote:
> A general purpose host or firewall is NOTHING like a mail server.
> There is no race condition in a mail server, because the server simply
> waits until the DNS query is returned.  No user is watching the mail
> queue, if mail is delayed by 1/10 of a second, or even many seconds,
> nothing happens.
>
> Now magine every web page you visit is suddenly paused by 100ms, or
> 1000ms, or multiple seconds?  Imagine that times 100s or 1000s of
> users.  Imagine what your call center would look like the day after
> you implemented it.  (Hint: Something like a smoking crater.)
>
> There might be ways around this (e.g. zone transfer / bulk load), but
> it is still not a good idea.
>
> Of course I could be wrong.  You shouldn't trust me on this, you
> should try it in production.  Let us know how it works out.

Andrew, IIUC, suggested that the default would be to allow while the
check was performed.

-Jim P.

Re: IBM report reviews Internet crime

[Jim Popovitch]

On Feb 12, 2008 3:27 PM,  <[EMAIL PROTECTED]> wrote:
> Not necessarily - it's unclear they mean "the vuln innately can't be fixed
> by a mere patch, because it's a social engineering issue", or "the vuln can't
> be fixed because the vendor has not yet shipped a patch for some reason".

... or the patch application mechanism isn't likely to be successful
against sufficiently infected machines.

-Jim P.

Re: Mailing list newbies suggestion

[Jim Popovitch]

On Sat, Mar 22, 2008 at 8:27 PM, Keith O'Neill <[EMAIL PROTECTED]> wrote:
>
>  I am not sure why this is an issue. Someone asked a question about
>  multihoming and the way I see it if you don't want to respond to it or
>  don't want to read it than don't. Why does this have to be a major
>  issue. I read what I want and respond to what I want. I think the rest
>  of the community can do the same.

I completely agree.   As mostly a reader of NANOG, I would rather read
70+ responses to multihoming best practices based on decades of
experience from some of the most respected senior network engineers to
date.  Sadly what we get is 70+ responses, from some of the most
respected senior network engineers to date,  debating what is and
isn't a good question or what isn't or isn't a good place to ask a
question.  :-(

-Jim P.

Re: [NANOG] [Nanog] attempt to capture nominet board

[Jim Mercer]

On Thu, Apr 24, 2008 at 03:01:31PM +0100, Neil J. McRae wrote:
> Yes strongly agreed and Randy thanks for raising this here.

as i recall, CIRA, the Canadian equivilent of Nominet, a few years ago, made
some serious changes to its structure/by-laws/etc in order to prevent/reduce
the possibility of a similar "take-over".

other registries might want to take note.


> 
> -Original Message-
> From: Randy Bush <[EMAIL PROTECTED]>
> Sent: 24 April 2008 11:30
> To: North American Network Operators Group <[EMAIL PROTECTED]>
> Subject: [Nanog] attempt to capture nominet board
> 
> dear uk sisters, brothers, and undecideds,
> 
> if you are a nomintet voting member or know someone who is, i strongly
> encourage you to read these two documents,
> <http://www.nominet.org.uk/governance/board/election/> and particularly
> <http://www.nominet.org.uk/digitalAssets/28780_call_to_action_letter_web.pdf>,
> and to vote the candidates running against the greedy domainer slime
> trying to capture nominet.
> 
> thanks for listening.
> 
> randy
> 
> ___
> NANOG mailing list
> NANOG@nanog.org
> http://mailman.nanog.org/mailman/listinfo/nanog
> 
> 
> ___
> NANOG mailing list
> NANOG@nanog.org
> http://mailman.nanog.org/mailman/listinfo/nanog

-- 
Jim Mercer[EMAIL PROTECTED]+971 55 410-5633
"I'm Prime Minister of Canada, I live here and I'm going to take a leak."
   - Lester Pearson in 1967, during a meeting between himself and
President Lyndon Johnson, whose Secret Service detail had taken over
Pearson's cottage retreat.  At one point, a Johnson guard asked
Pearson, "Who are you and where are you going?"

___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog

Re: [NANOG] would ip6 help us safeing energy ?

[Jim Popovitch]

On Mon, Apr 28, 2008 at 9:01 AM, Dale Carstensen <[EMAIL PROTECTED]> wrote:
>  I think Disney/ABC thinks they can get individual ISPs to pay them
>  to carry sports audio/video streams.  I suppose that would be yet
>  another multicast stream method, assuming an ISP location had multiple
>  customers viewing the same stream.
>
>  Are other content providers trying to do something similar?  How are
>  operators dealing with this?  What opinions are there in the operator
>  community?

I'm not sure of the particulars, but Hulu (NBC/Universal and News
Corp)  and FanCast (Comcast) seem to have an interesting relationship.
 I would love to know more, but i detest reading financials. ;-)

-Jim P.

___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog

Re: [NANOG] Comcast latency

[Jim Popovitch]

On Wed, Apr 30, 2008 at 8:14 AM, Steven M. Bellovin <[EMAIL PROTECTED]> wrote:
> On Tue, 29 Apr 2008 23:43:46 -0500
>  mack <[EMAIL PROTECTED]> wrote:
>
>  > Has anyone else noticed a significant increase in latency within
>  > Comcast's network?
>  >
>  On one quick test, it looks normal to me from my house.

Looks can sometimes be deceiving. ;-)  I've seen Comcast drop packets
left and right, but show 8Mbs/2Mbs on speed test sites.   Other times
I've seen the opposite, zero PL but extremely high latency (seconds,
double digits!)... all the while non-dynamic web pages (probably
cached upstream) loaded just fine.

Look, I've always been a big fan of Comcast but at this point I
suspect they have just about over-engineered their network.

-Jim P.

___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog

Re: FCCs RFC for the Definition of Broadband

[jim deleskie]

I agree we should all be telling the FCC that broadband is fiber to
the home.  If we spend all kinds of $$ to build a 1.5M/s connection to
homes, it's outdated before we even finish.



On Wed, Aug 26, 2009 at 1:38 PM, Fred Baker wrote:
> If it's about stimulus money, I'm in favor of saying that broadband implies
> fiber to the home. That would provide all sorts of stimuli to the economy -
> infrastructure, equipment sales, jobs digging ditches, and so on. I could
> pretty quickly argue myself into suggesting special favors for deployment of
> DNSSEC, multicast, and IPv6. As in, use the stimulus money to propel a leap
> forward, not just waste it.
>
> On Aug 26, 2009, at 9:44 AM, Carlos Alcantar wrote:
>
>> I think the big push to get the fcc to define broadband is highly based
>> on the rus/ntia setting definitions of what broadband is.  If any anyone
>> has been fallowing the rus/ntia they are the one handing out all the
>> stimulus infrastructure grant loan money.  So there are a lot of
>> political reasons to make the definition of broadband a bit slower than
>> one would think.  I guess it doesn't hurt that the larger lec's with the
>> older infrastructure are shelling out the money to lobby to make sure
>> the definition stays as low as can be.  They don't want to see the gov
>> funding there competition.  Just my 2 cents.
>>
>> -carlos
>>
>> -Original Message-
>> From: Ted Fischer [mailto:t...@fred.net]
>> Sent: Wednesday, August 26, 2009 8:50 AM
>> To: nanog@nanog.org
>> Subject: Re: FCCs RFC for the Definition of Broadband
>>
>>
>>
>> Paul Timmins wrote:
>>>
>>> Fred Baker wrote:

 On Aug 24, 2009, at 9:17 AM, Luke Marrott wrote:

> What are your thoughts on what the definition of Broadband should be
>>
> going
> forward? I would assume this will be the standard definition for a
> number of
> years to come.


 Historically, narrowband was circuit switched (ISDN etc) and
>>
>> broadband

 was packet switched. Narrowband was therefore tied to the digital
 signaling hierarchy and was in some way a multiple of 64 KBPS. As the
>>
 term was used then, broadband delivery options of course included
 virtual circuits bearing packets, like Frame Relay and ATM.
>>>
>>> of or relating to or being a communications network in which the
>>> bandwidth can be divided and shared by multiple simultaneous signals
>>
>> (as
>>>
>>> for voice or data or video)
>>>
>>> That's my humble opinion. Let them use a new term, like "High Speed
>>> Internet".
>>>
>>>
>> Seconded
>>
>>
>>
>
>
>

Re: FCCs RFC for the Definition of Broadband

[jim deleskie]

Having worked for rather large MSO in past I can tell you the issue
with this that the cost man power and engineering time to go back and
replace today with 3-5 forward technology is mostly like more then
delta between copper and fiber today.

-jim

On Wed, Aug 26, 2009 at 6:39 PM, Richard Bennett wrote:
> They have a saying in politics to the effect that "the perfect is the enemy
> of the good." This is a pretty good illustration. We have the opportunity to
> improve connectivity in rural America through the wise expenditure of
> taxpayer funding, and it's best not to squander it by insisting on top-shelf
> fiber or nothing at all. Let's push the fiber a little deeper, and bridge
> the last 20,000 feet with something that won't be too expensive to replace
> in 3-5 years. The budget ($7B) just isn't there to give every barn some nice
> GigE fiber, even though it would make the cows happy.
>
> Richard Bennett
>
> -Original Message-
> From: Joe Abley [mailto:jab...@hopcount.ca]
> Sent: Wednesday, August 26, 2009 1:42 PM
> To: Fred Baker
> Cc: nanog@nanog.org
> Subject: Re: FCCs RFC for the Definition of Broadband
>
>
> On 26-Aug-2009, at 13:38, Fred Baker wrote:
>
>> If it's about stimulus money, I'm in favor of saying that broadband
>> implies fiber to the home.
>
> I'm sure I remember hearing from someone that the timelines for disbursement
> of stimulus money were tight enough that many people expected much of the
> money to remain unspent.
>
> Does narrowing the scope of the funding to mandate fibre have the effect of
> funding more and better infrastructure, or will it simply result in less
> money being made available? Does it matter?
>
>
>
>
>

Re: FCCs RFC for the Definition of Broadband

[jim deleskie]

And 640k is enough. When I started in this game 15 or so yrs back the
'backbone' in Canada was a 56k figure 8 loop, running frame relay.  We
moved to T1 a yr or so later.  Buy the time I left Canada to work for
internetMCI a yr later, we're @ DS3's in Canada.  Technology evolves
quickly.  Just because some place does not have 'high-speed' internet
now, doesn't mean they will not in 5 yrs.  I sure we could site here
and site all the places in the world they will not due to
politics/poverty/all other bad things in the world, but its not reason
to limit the goals of people that are part of these projects.

-jim

On Wed, Aug 26, 2009 at 7:17 PM, Deepak Jain wrote:
> Key characteristics of broadband : always on capability (reasonably, DSL ok, 
> dial up no). I would argue 7mb is broadband even if its over carrier pigeon. 
> (meets always on criteria).
>
> I think the threshold for cut off is somewhere between 256kbit/s and 
> 1.5mbit/s. If you don't think 1.5mbit is broadband, you need to consider 
> tiers... Most of the worlds population will not see *that* speed in 20yrs.
>
> Deepak
>
> - Original Message -
> From: Jeffrey Lyon 
> To: nanog@nanog.org 
> Sent: Wed Aug 26 19:09:47 2009
> Subject: Re: FCCs RFC for the Definition of Broadband
>
> I would argue that "broadband" is the upper X percentile of bandwidth
> options available to residential users. For instance, something like
> Verizon FiOS would be broadband while a 7 Mbps cable wouldn't.
>
> Jeff
>
> On Wed, Aug 26, 2009 at 6:39 PM, Richard Bennett wrote:
>> They have a saying in politics to the effect that "the perfect is the enemy
>> of the good." This is a pretty good illustration. We have the opportunity to
>> improve connectivity in rural America through the wise expenditure of
>> taxpayer funding, and it's best not to squander it by insisting on top-shelf
>> fiber or nothing at all. Let's push the fiber a little deeper, and bridge
>> the last 20,000 feet with something that won't be too expensive to replace
>> in 3-5 years. The budget ($7B) just isn't there to give every barn some nice
>> GigE fiber, even though it would make the cows happy.
>>
>> Richard Bennett
>>
>> -Original Message-
>> From: Joe Abley [mailto:jab...@hopcount.ca]
>> Sent: Wednesday, August 26, 2009 1:42 PM
>> To: Fred Baker
>> Cc: nanog@nanog.org
>> Subject: Re: FCCs RFC for the Definition of Broadband
>>
>>
>> On 26-Aug-2009, at 13:38, Fred Baker wrote:
>>
>>> If it's about stimulus money, I'm in favor of saying that broadband
>>> implies fiber to the home.
>>
>> I'm sure I remember hearing from someone that the timelines for disbursement
>> of stimulus money were tight enough that many people expected much of the
>> money to remain unspent.
>>
>> Does narrowing the scope of the funding to mandate fibre have the effect of
>> funding more and better infrastructure, or will it simply result in less
>> money being made available? Does it matter?
>>
>>
>>
>>
>>
>
>
>
> --
> Jeffrey Lyon, Leadership Team
> jeffrey.l...@blacklotus.net | http://www.blacklotus.net
> Black Lotus Communications of The IRC Company, Inc.
>
> Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 -
> 21 to find out how to "protect your booty."
>
>

Re: FCCs RFC for the Definition of Broadband

[jim deleskie]

Why should I person be disadvantage from another in the same country,
maybe its the Canadian in me, but isn't there something in the
founding documents of the US that define's all men as being equal.  I
though it was Orewell that made some more equal then others. :)

-jim

On Wed, Aug 26, 2009 at 8:00 PM, Roy wrote:
> I think it has become obvious that the correct definition of broadband
> depends on the users location.  A house in the boonies is not going to get
> fiber,  Perhaps the minimum acceptable bandwidth should vary by area.  A
> definition of "area" could be some sort of user density measurement by
> census tract.
>
>
> Deepak Jain wrote:
>>
>> Key characteristics of broadband : always on capability (reasonably, DSL
>> ok, dial up no). I would argue 7mb is broadband even if its over carrier
>> pigeon. (meets always on criteria).
>>
>> I think the threshold for cut off is somewhere between 256kbit/s and
>> 1.5mbit/s. If you don't think 1.5mbit is broadband, you need to consider
>> tiers... Most of the worlds population will not see *that* speed in 20yrs.
>>
>> Deepak
>>
>> - Original Message -
>> From: Jeffrey Lyon 
>> To: nanog@nanog.org 
>> Sent: Wed Aug 26 19:09:47 2009
>> Subject: Re: FCCs RFC for the Definition of Broadband
>>
>> I would argue that "broadband" is the upper X percentile of bandwidth
>> options available to residential users. For instance, something like
>> Verizon FiOS would be broadband while a 7 Mbps cable wouldn't.
>>
>> Jeff
>>
>> On Wed, Aug 26, 2009 at 6:39 PM, Richard Bennett
>> wrote:
>>
>>>
>>> They have a saying in politics to the effect that "the perfect is the
>>> enemy
>>> of the good." This is a pretty good illustration. We have the opportunity
>>> to
>>> improve connectivity in rural America through the wise expenditure of
>>> taxpayer funding, and it's best not to squander it by insisting on
>>> top-shelf
>>> fiber or nothing at all. Let's push the fiber a little deeper, and bridge
>>> the last 20,000 feet with something that won't be too expensive to
>>> replace
>>> in 3-5 years. The budget ($7B) just isn't there to give every barn some
>>> nice
>>> GigE fiber, even though it would make the cows happy.
>>>
>>> Richard Bennett
>>>
>>> -Original Message-
>>> From: Joe Abley [mailto:jab...@hopcount.ca]
>>> Sent: Wednesday, August 26, 2009 1:42 PM
>>> To: Fred Baker
>>> Cc: nanog@nanog.org
>>> Subject: Re: FCCs RFC for the Definition of Broadband
>>>
>>>
>>> On 26-Aug-2009, at 13:38, Fred Baker wrote:
>>>
>>>
>>>>
>>>> If it's about stimulus money, I'm in favor of saying that broadband
>>>> implies fiber to the home.
>>>>
>>>
>>> I'm sure I remember hearing from someone that the timelines for
>>> disbursement
>>> of stimulus money were tight enough that many people expected much of the
>>> money to remain unspent.
>>>
>>> Does narrowing the scope of the funding to mandate fibre have the effect
>>> of
>>> funding more and better infrastructure, or will it simply result in less
>>> money being made available? Does it matter?
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>

Re: FCCs RFC for the Definition of Broadband

[jim deleskie]

Wrong analogy, you have no way to use all 6 lanes @ once.  The highway
is an aggregation device not access method.  Unless you have 6 lanes
into your driveway :)

On Wed, Aug 26, 2009 at 10:11 PM, Chris Adams wrote:
> Once upon a time, jim deleskie  said:
>> Why should I person be disadvantage from another in the same country,
>> maybe its the Canadian in me, but isn't there something in the
>> founding documents of the US that define's all men as being equal.
>
> Nobody is forcing anybody to live out where high-speed Internet is not
> currently feasible (or at least not at a price that those residents want
> to pay).  I live half a mile from a six lane highway; that doesn't mean
> that we have to build six lane highways to within half a mile of
> everybody in the country.
>
> --
> Chris Adams 
> Systems and Network Administrator - HiWAAY Internet Services
> I don't speak for anybody but myself - that's enough trouble.
>
>

Issues with Gmail

[Jim Wininger]

Anyone else seeing issues with gmail?
-- 
Jim Wininger

Re: Invalid prefix announcement from AS9035 for 129.77.0.0/16

[Jim Cowie]

Lots of people were affected, but none significantly.   They originated
86,747 networks very briefly (less than a minute at 7:23 UTC), and I don't
think anyone outside Telecom Italia's customer cone even saw them.   So the
impact was really, really limited.  The correct origins were being
reasserted even before the last of the announcements came over the wire.

It always irks me when I see "routing alerts" that arrive hours after the
event is over, without any of the context that would allow you to know
whether it had any real impact.   Your instinct to check looking glasses is
the right one, but you have to move quickly and know where to look.

Of course, I'm biased.--jim



On Fri, Oct 9, 2009 at 9:20 AM, Adam Kennedy wrote:

> Agreed. Our prefixes at AS40060 were announced as well. I received a
> notification around 7:00am EDT that our prefixes were detected announced
> from AS9035 with the same upstream AS1267.
>
>
> On 10/9/09 8:34 AM, "Wouter Prins"  wrote:
>
> > Hi Matthew,
> > You are not the only one having this issue. They are announcing some
> other
> > prefixes as well!
> >
> > 2009/10/9 Matthew Huff 
> >
> >> About 4 hours ago BGPmon picked up a rogue announcement of 129.77.0.0
> from
> >> AS9035 (ASN-WIND Wind Telecomunicazioni spa) with an upstream of AS1267
> >> (ASN-INFOSTRADA Infostrada S.p.A.). I don't see it now on any looking
> glass
> >> sites. Hopefully this was just a typo that was quickly corrected. I
> would
> >> appreciate if people have time and can double check let me know if any
> >> announcements are active except from our AS6128/AS6395 upstreams.
> >>
> >> If this were to persist, what would be the best course of action to
> resolve
> >> it, especially given that the AS was within RIPE.
> >>
> >>
> >> 
> >> Matthew Huff   | One Manhattanville Rd
> >> OTA Management LLC | Purchase, NY 10577
> >> http://www.ox.com  | Phone: 914-460-4039
> >> aim: matthewbhuff  | Fax:   914-460-4139
> >>
> >>
> >>
> >>
> >
>
> --
> Adam Kennedy
> Senior Network Administrator
> Cyberlink Technologies, Inc.
> Phone: 888-293-3693 x4352
> Fax: 574-855-5761
>
>
>

Re: Science vs. bullshit

[Jim Cowie]

Randy's right that it can be somewhat difficult to agree on a single
methodology for generating accurate assessments of how many transit
providers a particular network uses at a particular moment in time.
There are at least two knobs to turn: how long you integrate updates (we
like to use at least 24 hours of continuous time in order to flush out
backup routes, but it's sensible to look for weeks or longer to get the real
rarities to show their heads), and how much peer diversity you require in
order to call a provider relationship 'globally visible transit' for a given
prefix (I used 50+ peers as a rough rule of thumb, but you can pick
lower/higher numbers and get arguably meaningful answers).   It's like
asking, "how big is the global routing table .. REALLY?"   Depends on how
you count.

The thing about the data I presented, however, is that it is _differential_
... it says "set your knobs, look at four days over four years, and let's
see if the migration among populations seems consistent."   In fact, the
recurrence is pretty stable -- the same percentage of people in "diversity
class X" tend to end up in "diversity class Y" twelve months later, over
multiple years, with small changes that we can identify as trends.  This
gives confidence that the knobs are set in such a way that they are
achieving some meaningful classification of the prefix population.

To Patrick's point, the shape of the curve tells us useful things, even if
the precise boundaries among diversity classes can be drawn in subtly
different ways.

And that's exactly why we look for techniques that can give information
about trends (for example, my point that some dual-homed ASNs appear to be
postponing their decision to attain higher degrees of multihoming) even in
the presence of some classification uncertainty at the single-prefix level.

I'm glad to have sparked so much excitement with a 10-minute talk.   Imagine
if I had dragged it out to 30 minutes!

cheers, ---jim



On Mon, Oct 19, 2009 at 4:05 PM, Patrick W. Gilmore wrote:

> Lightning talk followup because I want to make sure there was not a
> miscommunication.  A two sentence comment at the mic while 400+ of your
> not-so-close friends are watching does not a rational discussion make.
>
> The talk in question:
>
>   <
> http://nanog.org/meetings/nanog47/presentations/Lightning/Cowie_Recession_lightning_N47.pdf
> >
>
> The disagreement is whether Renesys can reliably find out how many transit
> providers an AS has.  Remember, we are discussing transit providers here,
> not peers.
>
> My point is if an AS has _transit_, then it must be visible in the global
> table (assuming a reasonably large set of vantage points), or it would not
> be transit.  Of course, this is not perfect, but it is a pretty close
> approximation for fitting curves over 10s of 1000s of ASes.  So things like
> "I have two transit providers, and one buys transit from the other" is a
> small number and not relevant to fitting curves.  (It also means you are an
> idiot, or in a corner of the Internet where you should probably be
> considered as having only one provider.)
>
> Majdi has pointed out other corner cases where transit is not viewable
> through systems like Rensys.  For instance, announcing prefixes to Provider
> 2 with a community to local-pref the announcement below peer routes.  That
> means only one transit is visible in BGP data.
>
> There were several reasons some of us did not think edge cases like this
> were important.  For instance, Renesys keeps -every- update ever, so if
> Provider 1 ever flaps, Rensys will see Provider 2.  Also, when looking for
> the number of providers, a "backup path" may not be relevant since no
> packets take that path.
>
> More importantly, I thought the point of the talk was to show that the
> table was growing during the recession and people were still getting more
> providers.  The result is a curve, not a hard-and-fast number.  Corner cases
> like the one above are barely noise, so the curve it still valid.
>
> It is true that finding peering edges with things like route-views is
> problematic at best, so finding ASes with one transit plus peering might be
> problematic.  But since I do not think that was the point of the talk, I do
> not consider that problem.
>
>
> If anyone who still thinks the problems with finding transit edges somehow
> make the talk 'bullshit' could clarify their position, I would be grateful.
>
> --
> TTFN,
> patrick
>
>
>

Re: Upstream BGP community support

[jim deleskie]

Here is the problem as I see it.  Sure some % fo the people using BGP
are bright nuff to use some upstreams communities, but sadly many are
not.  So this ends up breaking one or more networks, who in turn twist
more dials causing other changes.. rinse, wash and repeat.  But like
Randy said who am I to stop anyone from playing... just means those of
us with clue will be able to continue to earn a pay check for a very
long time still :)

-jim

On Sat, Oct 31, 2009 at 9:25 PM, Randy Bush  wrote:
> while i can understand folk's wanting to signal upstream using
> communities, and i know it's all the rage.  one issue needs to be
> raised.
>
> bgp is a brilliant information hiding protocol.  policy is horribly
> opaque.  complexity abounds.  and it has unfun consequences, e.g. see
> tim on wedgies etc.
>
> and this just adds to the complexity and opacity.
>
> so i ain't sayin' don't do it.  after all, who would deny you the
> ability to show off your bgp macho?
>
> just try to minimize its use to only when you *really* need it.
>
> randy
>
>

Re: Upstream BGP community support

[jim deleskie]

Agree'd :)

On Sat, Oct 31, 2009 at 9:34 PM, Randy Bush  wrote:
>> Here is the problem as I see it.  Sure some % fo the people using BGP
>> are bright nuff to use some upstreams communities, but sadly many are
>> not.  So this ends up breaking one or more networks, who in turn twist
>> more dials causing other changes.. rinse, wash and repeat.  But like
>> Randy said who am I to stop anyone from playing... just means those of
>> us with clue will be able to continue to earn a pay check for a very
>> long time still :)
>
> i would rather earn it by designing things, not by cleaning up messes
> made by kiddies needing to show off.
>
> randy
>

kaspersky anti-virus tech, with a clue?

[Jim Mercer]

it seems that kaspersky anti-virus is "detecting" our hotspot captive portal
login as a "Trojan-Downloader.Script.Generic".

my googling on this seems to indicate that it isn't finding so much a
signature, but something in the url that is "suspicious".

unfortunately, this is causing some fairly unhappy, panicing calls to our
support people from customers.

can anyone point me at a Kaspersky tech with a clue?  maybe we can re-craft
our login url to not offend the Kaspersky suite.

note: this hotspot suite has been in operation for 4+ years, and is based on
the chillispot portal.

note: these reports only started recently, so i suspect something was added to
Kaspersky's virus database recently that kicked this off.

-- 
Jim Mercerj...@reptiles.org+92 336 520-4504
"I'm Prime Minister of Canada, I live here and I'm going to take a leak."
   - Lester Pearson in 1967, during a meeting between himself and
President Lyndon Johnson, whose Secret Service detail had taken over
Pearson's cottage retreat.  At one point, a Johnson guard asked
Pearson, "Who are you and where are you going?"

Re: news from Google

[Jim Richardson]

On Fri, Dec 11, 2009 at 1:07 PM, Seth Mattinen  wrote:
> Peter Beckman wrote:


> Here's a pretty common line that Microsoft has that Google completely omits
> (or that I can't find):
>
> "We do not sell, rent, or lease our customer lists to third parties."
>
> ~Seth
>
>

You aren't Bing's customer, you are a user. The line you quote, even
if they follow it, would not prohibit them from selling any and all
information they get from your searches.

*yahoo* is Bing's customer.

-- 
http://neon-buddha.net

Re: IPv6 Training

[Jim Burwell]

On 12/23/2009 13:03, Mike Leber wrote:
>
> Marty Anstey wrote:
>> Just wondering if anyone has had any experience with IPv6 training
>> courses.
>>
>> A quick search turns up a few results on the subject, but it would be
>> handy to hear if anyone has any firsthand experiences or
>> recommendations.
>> We're based in western Canada but don't mind traveling a bit, but
>> alternatively an online course would be acceptable as well.
>
> Once you have IPv6 connectivity established (either native IPv6 or via
> a tunnel from anybody (for example tunnelbroker.net or sixxs.net) if
> you want a self teaching procedural guide where you can setup and test
> various IPv6 services (HTTP, SMTP, reverse DNS, forward DNS, host
> record glue) then you might checkout our free IPv6 certification
> service at:
>
> http://ipv6.he.net/certification
>
> It's a bit tongue in cheek and meant to be sort of like entertainment
> with education for engineers (for example the certification ranks are
> from "Newb" to "Sage").  By the time you are done you are done IPv6
> won't seem weird.  (In fact, you'll probably be thinking "that's it?!")
>
Tongue in cheek?  You mean I'm not *really* a Sage?  :p :p

The tunnelbroker.net forum is also a good source of info/discussion
about IPv6.  It'd be nice if it was a bit more "active" though.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Revisiting the Aviation Safety vs. Networking discussion

[Jim Shankland]

Eddy Martinez wrote:

On Dec 24, 2009, at 10:09 AM, Randy Bush wrote:


I _do_ create action plans and _do_ quarterback each step and _do_
slap down any attempt to deviate.

imagine a network engineering culture where the concept of 'attempt to
deviate' just does not occur.


I find the thought of *any* culture in which attempts to deviate
"just do not occur" a little unnerving.

Jim Shankland

http://blog.oliver-gassner.de/archives/225-Guenter-Eich,-Traeume.html

Re: D/DoS mitigation hardware/software needed.

[jim deleskie]

What Roland said, I've seen people do this, no rules in place, still
was able to kill the box (firewall) with a single CPU server.

-jim

On Mon, Jan 4, 2010 at 10:04 PM, Dobbins, Roland  wrote:
>
> On Jan 5, 2010, at 4:25 AM, Jeffrey Lyon wrote:
>
>> Use a robust firewall such as a Netscreen in front of your mitigation
>> tool.
>
> Absolutely not - the firewall will fall over due to state-table exhaustion 
> before the mitigation system will.  Firewalls (which have no place in front 
> of servers in the first place), load-balancers, and any other stateful 
> devices should be southbound of the mitigation system.
>
> ---
> Roland Dobbins  // <http://www.arbornetworks.com>
>
>    Injustice is relatively easy to bear; what stings is justice.
>
>                        -- H.L. Mencken
>
>
>
>
>

Re: Default Passwords for World Wide Packets/Lightning Edge Equipment

[Jim Burwell]

On 1/6/2010 01:23, Dobbins, Roland wrote:
> On Jan 6, 2010, at 4:18 PM, Matthew Palmer wrote:
>
>   
>> The closest I can come to a solution is to set a random password and flash 
>> it using a front-panel LED using morse.  
>> 
> heh
>
> No password at all, operator prompted at the console during startup 
> unless/until he sets one.  No IP address, et. al. until a password is set.
>   
Yeah.  And for devices with no console, only network interfaces, a
default IP address, no default password, and no default route (just in
case they plug it into a real LAN instead of a laptop.  :p  ).

Re: Are IPv6-only Internet services viable today?

[Jim Burwell]

On 1/14/2010 11:10, Cameron Byrne wrote:
> Folks,
>
> My question to the community is:  assuming a network based IPv6 to IP4
> translator is in place (like NAT64 / DNS64), are IPv6-only Internet
> services viable as a product today?  In particular, would it be
> appropriate for a 3G /smartphone or wireless broadband focused on at
> casual (web and email) Internet users?  Keep in mind, these users have
> NAT44 today.
>   
You may also want to read up on Dual Stack Lite (DS-Lite)
,
presuming you haven't.  I know you mentioned you didn't like any
dual-stack solutions, but the thing about DS-Lite I like is that it has
no problem with RFC1918 overlap of different customers, since the CGN
uses a tunnel ID in the connection/NAT table in addition to the other
typical data.  I just wonder how it will scale, since each device, or a
gateway the device goes though, will require a IPv4-in-IPv6 tunnel to
the CGN box(es).  Also, it doesn't require a DNS-ALG like NAT64/DNS64.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Are IPv6-only Internet services viable today?

[Jim Burwell]

Sorry for late response here...

On 1/14/2010 15:20, Cameron Byrne wrote:
> On Thu, Jan 14, 2010 at 3:00 PM, Jim Burwell  wrote:
>   
>> On 1/14/2010 11:10, Cameron Byrne wrote:
>> 
>>> Folks,
>>>
>>> My question to the community is:  assuming a network based IPv6 to IP4
>>> translator is in place (like NAT64 / DNS64), are IPv6-only Internet
>>> services viable as a product today?  In particular, would it be
>>> appropriate for a 3G /smartphone or wireless broadband focused on at
>>> casual (web and email) Internet users?  Keep in mind, these users have
>>> NAT44 today.
>>>
>>>   
>> You may also want to read up on Dual Stack Lite (DS-Lite)
>> <http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-02>,
>> 
> I have looked at DS-lite very carefully.   First, DS-Lite fits better
> for cable operators since they have CPE and can have a DS-lite
> function in the CPE that they control, and that in turn allows them to
> provide IPv4, IPv6, and dual-stack to the end-host that they do not
> control.  DS-Lite does not fit as well for a mobile phones since it
> would require a major change to the phone's OS.  Second, DS-Lite
> requires tunneling as well as translation, so it is one more piece of
> overhead in addition to NAT64 solution.  For me, i believe it is less
> complex to manage a single stack IPv6 host with NAT64 translation than
> a dual stack host, tunneling infrastructure, as well as NAT44 CGN,
> which is what DS-lite requires.  They both achieve the same result,
> but I believe in the mobile space there is a quicker time to market as
> well as more progress toward the end-goal of IPv6-only using NAT64
> than DS-lite.
>   
I guess the choice here is between standing up and managing a NAT64 CGN
+ special DNS64 DNS server infrastructure, or a DS-Lite CGN + DS-Lite
tunneling infrastructure (you'd be able to keep existing "vanilla" DNS
servers).

Presuming you could set up DS-Lite capable routers somewhere in the
path, one nice thing about DS-Lite would be that you could allow a mix
of dual-stack phones, IPv4 only phones, and even DS-Lite capable phones
on the same network.  This could be an advantage if IPv6 stacks or
DS-Lite virtual nic/tunnel drivers weren't available on all customer
phones.  Also, as Mr. Durand mentioned earlier, DS-Lite has an advantage
in application compatibility too. 

And, admittedly getting a bit speculative here, by virtue of the fact
that a DS-Lite solution would give each phone an IPv4 address, "NAT
compatibility" of various applications may also be better on the CGN,
since NAT44 is so well understood and generally "worked out" today,
where a NAT64 CGN might not support as many "problem apps" which require
"fixups" as a DS-lite NAT44 CGN.

But if we can presume all phones will have IPv6, and all applications
running on them are IPv6 capable, then DNS64/NAT64 would in some ways be
cleaner, since it'd eliminate the traffic overhead of tunneling, etc. 
You'd just have to stand up and manage the DNS64 servers and NAT64 CGNs.

>> presuming you haven't.  I know you mentioned you didn't like any
>> dual-stack solutions, but the thing about DS-Lite I like is that it has
>> no problem with RFC1918 overlap of different customers, since the CGN
>> uses a tunnel ID in the connection/NAT table in addition to the other
>> typical data.  I just wonder how it will scale, since each device, or a
>> gateway the device goes though, will require a IPv4-in-IPv6 tunnel to
>> the CGN box(es).  Also, it doesn't require a DNS-ALG like NAT64/DNS64.
>> 
> NAT64/DNS64 does not use a DNS-ALG.  DNS-ALG died with NAT-PT.  DNS64
> is a standalone function which is decoupled from the translation
> process.
>   
Yeah this is improper terminology I suppose.  I use "DNS-ALG" in the
IPv6 transition context as a generic term for any specialized DNS server
which hacks IPv4 addresses into fake IPv6 addresses for these sorts of
purposes, which is further overloading the term I guess. :p  Not sure
what to use as a better generic term for this.

The point I was trying to make is that DS-Lite doesn't require any DNS
hackery, unlike NAT64/DNS64, for what it's worth.

Anyway, plenty to weigh/consider here.

PS:  Nice to see the author of the DS-Lite drafts participating here
too.  :)




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Are IPv6-only Internet services viable today?

[Jim Burwell]

On 1/15/2010 23:45, Owen DeLong wrote:
>
> On Jan 15, 2010, at 7:53 PM, Jim Burwell wrote:
>
>> Sorry for late response here...
>>
>> On 1/14/2010 15:20, Cameron Byrne wrote:
>>> On Thu, Jan 14, 2010 at 3:00 PM, Jim Burwell >> <mailto:j...@jsbc.cc>> wrote:
>>>
>>>> On 1/14/2010 11:10, Cameron Byrne wrote:
>>>>
>>>>> Folks,
>>>>>
>>>>> My question to the community is:  assuming a network based IPv6 to IP4
>>>>> translator is in place (like NAT64 / DNS64), are IPv6-only Internet
>>>>> services viable as a product today?  In particular, would it be
>>>>> appropriate for a 3G /smartphone or wireless broadband focused on at
>>>>> casual (web and email) Internet users?  Keep in mind, these users have
>>>>> NAT44 today.
>>>>>
>>>>>
>>>> You may also want to read up on Dual Stack Lite (DS-Lite)
>>>> <http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-02>,
>>>>
>>> I have looked at DS-lite very carefully.   First, DS-Lite fits better
>>> for cable operators since they have CPE and can have a DS-lite
>>> function in the CPE that they control, and that in turn allows them to
>>> provide IPv4, IPv6, and dual-stack to the end-host that they do not
>>> control.  DS-Lite does not fit as well for a mobile phones since it
>>> would require a major change to the phone's OS.  Second, DS-Lite
>>> requires tunneling as well as translation, so it is one more piece of
>>> overhead in addition to NAT64 solution.  For me, i believe it is less
>>> complex to manage a single stack IPv6 host with NAT64 translation than
>>> a dual stack host, tunneling infrastructure, as well as NAT44 CGN,
>>> which is what DS-lite requires.  They both achieve the same result,
>>> but I believe in the mobile space there is a quicker time to market as
>>> well as more progress toward the end-goal of IPv6-only using NAT64
>>> than DS-lite.
>>>
>> I guess the choice here is between standing up and managing a NAT64 CGN
>> + special DNS64 DNS server infrastructure, or a DS-Lite CGN + DS-Lite
>> tunneling infrastructure (you'd be able to keep existing "vanilla" DNS
>> servers).
>>
>>
> As I understand DS-Lite, an IPv6-capable device is a DS-Lite capable
> device
> without any modification.  The DS-Lite Gateway does all the heavy lifting
> to provide IPv4 services and do the NAT64 translation between the
> IPv6-only
> end-user device (phone) and the IPv4 internet.
>
Could well be the case.  My idea was that you could do it either way. 
You could have a DS-Lite gateway (Typical.  Likely built into the "cable
modem" or similar device), or in the case where no gateway is available,
a DS-Lite "client" (basically a virtual nic/tunnel driver) on the
machine would establish the tunnel and an IPv4 address itself.  But
perhaps this latter method was never intended?


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Are IPv6-only Internet services viable today?

[Jim Burwell]

On 1/16/2010 07:01, Antonio Querubin wrote:
> On Sat, 16 Jan 2010, Cam Byrne wrote:
>
>> interested you can read the ietf draft.  Assuming you have a ds-lite
>> cpe, you can park dual-stack hosts behind it.  But, it does not "just
>
> If your hosts are dual-stacked, why would you need a ds-lite cpe in
> the first place?
>
The point of DS-Lite is to provide IPv4 internet access to hosts which
only have IPv6 addresses in an IPv6 only network environment.  That is,
IPv4 connectivity isn't available all the way through to the provider's
CGN.  If you did straight dual-stack, the provider would have to do IPv4
connectivity all the way to the CGN, and also maintain unique RFC1918 IP
address assignments to every customer going through a particular CGN. 
With DS-Lite, the IPv4 traffic is tunneled from a DS-Lite router
fronting the customer's LAN, or from a host itself (a presumption)
running some sort of DS-Lite driver.  Because the traffic can by
identified by the CGN from the tunnel it came in on, the RFC1918s don't
have to be unique (the customer can pick whatever he wants for his/her
LAN).  A full DS network isn't needed throughout the entire provider
infrastructure, hence the name DS "Lite". 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: ASR1002

[Jim Mercer]

On Tue, Jan 19, 2010 at 05:20:59PM +0900, Randy Bush wrote:
> > Who knows how to unsubscribe the mail list?
> 
> look at the headers

i still read most of my mail with mutt, but in my experience, many "modern"
interfaces (gmail/thunderrbird/etc) don't make it intuative to find and/or
read the headers.

i'm just sayin'


> 
> List-Unsubscribe: <http://mailman.nanog.org/mailman/listinfo/nanog>,  
> <mailto:nanog-requ...@nanog.org?subject=unsubscribe>
> List-Archive: <http://mailman.nanog.org/mailman/nanog>
> List-Post: <mailto:nanog@nanog.org>
> List-Help: <mailto:nanog-requ...@nanog.org?subject=help>
> List-Subscribe: <http://mailman.nanog.org/mailman/listinfo/nanog>,
> <mailto:nanog-requ...@nanog.org?subject=subscribe>
> 
> randy

-- 
Jim Mercerj...@reptiles.org+92 336 520-4504
"I'm Prime Minister of Canada, I live here and I'm going to take a leak."
   - Lester Pearson in 1967, during a meeting between himself and
President Lyndon Johnson, whose Secret Service detail had taken over
Pearson's cottage retreat.  At one point, a Johnson guard asked
Pearson, "Who are you and where are you going?"

Re: New netblock Geolocate wrong (Google)

[Jim Mercer]

On Tue, Jan 19, 2010 at 09:23:41PM +0900, Randy Bush wrote:
> surely, with its vast talents, the ietf can make this more complex.
> 
> after all, look at the inflate-and-embellish stupidity that made the
> simple idea of bgp communities for data collecion, completely ueless,
> draft-meyer-collection-communities-00.txt
> 
> 

sorta like how RFC1530, over the course of 10 years, plus some ITU fiddling,
became RFC3761

its interesting how many wheels seem to need re-inventing.

8^)

-- 
Jim Mercerj...@reptiles.org+92 336 520-4504
"I'm Prime Minister of Canada, I live here and I'm going to take a leak."
   - Lester Pearson in 1967, during a meeting between himself and
President Lyndon Johnson, whose Secret Service detail had taken over
Pearson's cottage retreat.  At one point, a Johnson guard asked
Pearson, "Who are you and where are you going?"

OT: old farts recollecting -- Re: ASR1002

[Jim Mercer]

for days now, i've been trying to remember a quotation, which i vaguely seem
to remember popping up in trn/nn or some USENET newsreader of old, along
the lines of:

"the telephone, once commonly available in cities, "

or something like that.

ring a bell for anyone?

-- 
Jim Mercerj...@reptiles.org+92 336 520-4504
"I'm Prime Minister of Canada, I live here and I'm going to take a leak."
   - Lester Pearson in 1967, during a meeting between himself and
President Lyndon Johnson, whose Secret Service detail had taken over
Pearson's cottage retreat.  At one point, a Johnson guard asked
Pearson, "Who are you and where are you going?"

Re: OT: old farts recollecting -- Re: ASR1002

[Jim Mercer]

On Wed, Jan 20, 2010 at 08:30:52AM +, gordon b slater wrote:
> On Tue, 2010-01-19 at 17:42 -0800, Bill Stewart wrote:
> > Could the comment actually have been about pay telephones, which were
> > once common in cities?
> > 
> 
> Good point Bill, which, if so, would place the comment at or about the
> start of the cellfone introduction.
> 
> @Jim, maybe it's more a telco/2600 thing? 

found it, actually was once in my .signature:

"The telephone, for those of you who have forgotten, was a commonly used
communications technology in the days before electronic mail.
They're still easy to find in most large cities." -- Nathaniel Borenstein

i'm guessing this is before the mobile phone explosion.

-- 
Jim Mercerj...@reptiles.org+92 336 520-4504
"I'm Prime Minister of Canada, I live here and I'm going to take a leak."
   - Lester Pearson in 1967, during a meeting between himself and
President Lyndon Johnson, whose Secret Service detail had taken over
Pearson's cottage retreat.  At one point, a Johnson guard asked
Pearson, "Who are you and where are you going?"

Re: Idiotic Newstar Networking Equipment Sales Droid

[Jim Mercer]

On Wed, Jan 20, 2010 at 10:43:27AM -0800, Scott Weeks wrote:
> If they see all of us saying we won't buy from them when they do idiotic 
> things like spamming nanog folks (I can't think of too many groups it world 
> be worse to spam...  ;-) they will realize that doing this will not only not 
> generate sales, it will actually prevent future sales from occurring.

you are assuming they actually read the list.

-- 
Jim Mercerj...@reptiles.org+92 336 520-4504
"I'm Prime Minister of Canada, I live here and I'm going to take a leak."
   - Lester Pearson in 1967, during a meeting between himself and
President Lyndon Johnson, whose Secret Service detail had taken over
Pearson's cottage retreat.  At one point, a Johnson guard asked
Pearson, "Who are you and where are you going?"

policies for 24.0.0.0/8 ?

[Jim Mercer]

i'm doing some consulting work for a cable operator in Pakistan.

while i'm guessing that realistically we will be approaching RIPE for address
space, i'm just wandering what happened to 24.0.0.0/8 and what policies
govern who and what can use the address space there.

-- 
Jim Mercerj...@reptiles.org+92 336 520-4504
"I'm Prime Minister of Canada, I live here and I'm going to take a leak."
   - Lester Pearson in 1967, during a meeting between himself and
President Lyndon Johnson, whose Secret Service detail had taken over
Pearson's cottage retreat.  At one point, a Johnson guard asked
Pearson, "Who are you and where are you going?"

Re: policies for 24.0.0.0/8 ?

[Jim Mercer]

On Fri, Jan 22, 2010 at 10:07:35AM +, Nick Hilliard wrote:
> On 22/01/2010 05:07, Jim Mercer wrote:
> > i'm just wandering what happened to 24.0.0.0/8 and what policies
> > govern who and what can use the address space there.
> 
> Not quite sure why you'd want to use 24/8.  It became a "normal" address
> block a very long time ago .  RFC3330 sez:
> 
> >24.0.0.0/8 - This block was allocated in early 1996 for use in
...
> >Numbers (ARIN) in May 2001.  Addresses within this block are assigned
> >in the normal manner and should be treated as such.
> 
> So, it's just regular IP address space, available for assignment if you
> live in ARIN-land.

hrm, somehow i missed that.

> Incidentally, Pakistan is serviced by APNIC, not RIPE:
> 
> http://www.apnic.net/about-APNIC/organization/apnics-region

wow, musta been sleeping that day.

any how, it is what it is.

-- 
Jim Mercerj...@reptiles.org+92 336 520-4504
"I'm Prime Minister of Canada, I live here and I'm going to take a leak."
   - Lester Pearson in 1967, during a meeting between himself and
President Lyndon Johnson, whose Secret Service detail had taken over
Pearson's cottage retreat.  At one point, a Johnson guard asked
Pearson, "Who are you and where are you going?"

Re: Using /126 for IPv6 router links

[Jim Burwell]

On 1/25/2010 20:06, Mark Smith wrote:
>
> This from people who can probably do decimal to binary conversion
> and back again for IPv4 subnetting in their head and are proud of
> it. Surely IPv6 hex to binary and back again can be the new party
> trick? :-)
>
>
>   
Hehe.  Decimal -> binary in your head?  I don't even bother except if
it's some well known "magic #s".  Hex -> binary though is super simple
since unlike decimal, each digit translates exactly into a nybble.  You
just have to know the binary from 0 - 15, 16 simple four-bit patterns,
and it's a piece of cake.  You can give me hex numbers and and I'll
rattle off binary all day, or vica-versa.  Octal is similarly easy, but
would result in some long IPv6 addresses.  :-)



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Using /126 for IPv6 router links

[Jim Burwell]

On 1/26/2010 23:32, Mark Smith wrote:
>
> A minor data point to this, Linux looks to be implementing the
> subnet-router anycast address when IPv6 forwarding is enabled, as it's
> specifying Solicited-Node multicast address membership for the
> all zeros node address in it's MLD announcements when an interface
> comes up.
>
>   
Yes, I believe you are correct.  It appears to be implemented.  When I
ping the subnet anycast from a Linux or Windows XP box I get a reply
from the IPv6 router on my LAN.  The router is a Linux box running
Kernel 2.6.31.  Interestingly, on a Linux box, the ping6 command shows
the router's unicast address answering the pings (same goes for ping6
under Cygwin on a Windows box).  But on a Windows box ping shows the
anycast address answering.  However, in both cases packet captures show
it actually is the unicast address of the router answering, which I
believe is the expected behavior.  Windows ping just shows the wrong
address for whatever reason.



smime.p7s
Description: S/MIME Cryptographic Signature

google contact? why is google hosting/supporting/encouraging spammers?

[Jim Mercer]

we have recently started getting alot of spam, out of dubai, from 
"ecampaigners@gmail.com"

all of the spam comes from/through google and google groups.

is this accepted/supported activity on google?

if not, where might i find a contact who can cluefully respond?

-- 
Jim Mercerj...@reptiles.org+92 336 520-4504
"I'm Prime Minister of Canada, I live here and I'm going to take a leak."
   - Lester Pearson in 1967, during a meeting between himself and
President Lyndon Johnson, whose Secret Service detail had taken over
Pearson's cottage retreat.  At one point, a Johnson guard asked
Pearson, "Who are you and where are you going?"

Re: google contact? why is google hosting/supporting/encouraging spammers?

[Jim Mercer]

On Thu, Feb 04, 2010 at 12:35:06PM +0530, Suresh Ramasubramanian wrote:
> ab...@gmail.com maybe? Looks like some random spammer based in Dubai
> judging by the airport code.

yeah, tried that several times.  seems to go to a black hole.

i've engaged the spammer, and they are telling me that they feel it is ok to
subscribe people to their group, because it sends out a subscription notice,
as well as an unsubscribe link.

they seem to be quite happy to use an @gmail account, and use google groups to
propagate their spam.

most recently, i got from them: "Yes you are right, you can complain to Google, 
but to complain, you have a right email address, because this address we don't 
have listed."

so, they are not concerned about being reported to google.

very odd.

is this a legitimate google groups activity?

someone can set up and say "well, yeah, he musta gone to one of our websites
or something, how else would he get on our list?"

and google is ok with that?

geez, "do no harm"

really?

--jim

> 
> On Thu, Feb 4, 2010 at 11:37 AM, Jim Mercer  wrote:
> > we have recently started getting alot of spam, out of dubai, from 
> > "ecampaigners@gmail.com"
> >
> > all of the spam comes from/through google and google groups.
> >
> > is this accepted/supported activity on google?
> >
> > if not, where might i find a contact who can cluefully respond?
> 
> 
> 
> -- 
> Suresh Ramasubramanian (ops.li...@gmail.com)

-- 
Jim Mercerj...@reptiles.org+92 336 520-4504
"I'm Prime Minister of Canada, I live here and I'm going to take a leak."
   - Lester Pearson in 1967, during a meeting between himself and
President Lyndon Johnson, whose Secret Service detail had taken over
Pearson's cottage retreat.  At one point, a Johnson guard asked
Pearson, "Who are you and where are you going?"

Re: google contact? why is google hosting/supporting/encouraging spammers?

[Jim Mercer]

On Thu, Feb 04, 2010 at 02:49:42AM -0500, David Ford wrote:
> Google groups cautions you about pre-emptively adding people if you
> choose this method of subscribing them.

"here, have some free guns.  oh, by the way, its probably bad if you go around
shooting people, so don't do that."

it is starting too look to me like google is quite happy to host spammers.

or, at best, doesn't care if spammers use them to host their services.

> On 02/04/10 02:12, Jim Mercer wrote:
> > [...]
> > and google is ok with that?
> >
> > geez, "do no harm"
> >
> > really?
> >
> > --jim
> 

-- 
Jim Mercerj...@reptiles.org+92 336 520-4504
"I'm Prime Minister of Canada, I live here and I'm going to take a leak."
   - Lester Pearson in 1967, during a meeting between himself and
President Lyndon Johnson, whose Secret Service detail had taken over
Pearson's cottage retreat.  At one point, a Johnson guard asked
Pearson, "Who are you and where are you going?"

Re: google contact? why is google hosting/supporting/encouraging spammers?

[Jim Mercer]

On Thu, Feb 04, 2010 at 05:35:23PM -0600, Tony Varriale wrote:
> From: "Jim Mercer" 
> >we have recently started getting alot of spam, out of dubai, from 
> >"ecampaigners@gmail.com"
> >
> >all of the spam comes from/through google and google groups.
> 
> Not that I can point you in the correct direction, but Google Groups is a 
> haven for spammers.  In fact, I stopped using it a while ago for this 
> reason.

the issue for me is not that they are spamming groups within google groups,
but that they are signing up the victim email addresses as members of the
group, then using google groups to distribute the content.

-- 
Jim Mercerj...@reptiles.org+92 336 520-4504
"I'm Prime Minister of Canada, I live here and I'm going to take a leak."
   - Lester Pearson in 1967, during a meeting between himself and
President Lyndon Johnson, whose Secret Service detail had taken over
Pearson's cottage retreat.  At one point, a Johnson guard asked
Pearson, "Who are you and where are you going?"

Re: black listing of web traffic

[Jim Shankland]

Andrey Gordon wrote:

Can't find my IP on any of the black lists. Don't have any proxies. Sites
that behave poorly are consistent. That is to say that facebook.com,
apple.com would always come up without an issue, but cnn.com,
forever21.com(i know, don't ask, students),
store.apple.com would consistently take forever to come up.

Just wanted to check of rate-limiting web clients is a common practice
nowdays in the industry. If it's not, it's probably an unlikely cause of my
troubles...


Other things you might want to check out include whether your NAT
gateway is well-behaved in the presence of PMTU discovery, TCP
timestamps, and ECN.  The web sites your students are having trouble
with may share some property that, correctly or not, is interacting
poorly with your NAT implementation.

(I remain astonished at the number of "big name" web sites out there
that send out their content with the DF bit set, then drop the
"fragmentation required" ICMP packets they get back on the floor.)

Jim Shankland

Re: dns interceptors

[Jim Richardson]

On Fri, Feb 12, 2010 at 2:15 PM, Randy Bush  wrote:
> i just lost ten minutes debugging what i thought was a server problem
> which turned out to be a dns trapper on the wireless in the changi sats
> lounge.  this is not the first time i have been caught by this.
>
> what are other roaming folk doing about this?
>
> randy
>
>

ssh tunnels to IP address


-- 
http://neon-buddha.net

Re: Location of upstream connections & BGP templates

[jim deleskie]

Border/Core/Access is great thinking when your a sales rep for a
vendor that sells under power kit.  No reason for it any more.

-jim

On Wed, Feb 17, 2010 at 8:38 PM, Scott Weeks  wrote:
>
>
> --- st...@ibctech.ca wrote:
> From: Steve Bertrand 
>
> layered. My thinking is that my 'upstream' connections should be moved
> out of the core, and onto the edge. My reasoning for this is so that I
>
> What do other providers do? Are your transit peers connected directly to
> the core? I can understand such a setup for transit-only providers, but
> 
>
>
> Border, core, access.
>
> Border routers only connect the core to the upstreams.  They do nothing else. 
>  No acls, just prefix filters.  For example, block 1918 space from leaving 
> your network.  Block other bad stuff from leaving your network too.  Allow in 
> only what you're expecting from the upstream; again 1918 space, etc.  They 
> can fat finger like anyone else.
>
> Core is for moving bits as efficiently as possible: no acls; no filters.
>
> Connect downstream BGP customers to access routers that participate in the 
> iBGP mesh.  Filter them only allowing what they're supposed to advertise.  
> They'll mess it up a lot if they're like my customers by announcing 
> everything under the sun.  Filter what you're announcing to them.  You can 
> fat finger just as well as anyone else.  ;-)
>
> scott
>
>

Re: Location of upstream connections & BGP templates

[jim deleskie]

I've done it much larger then small networks. Dependency is much more
related to gear used then network size.

-jim

On Wed, Feb 17, 2010 at 8:46 PM, Scott Weeks  wrote:
>
>
> --- deles...@gmail.com wrote:
> From: jim deleskie 
>
>
> Border/Core/Access is great thinking when your a sales rep for a
> vendor that sells under power kit.  No reason for it any more.
> ---
>
>
> I'd imagine it depends on the network size.  Collapsing functionality is 
> doable for smaller sizes.  Please elaborate.
>
> scott
>
>

Re: Location of upstream connections & BGP templates

[jim deleskie]

Of course all designs are limited to the budget you have to build the
network :)

On Wed, Feb 17, 2010 at 9:20 PM, Steve Bertrand  wrote:
> On 2010.02.17 19:41, jim deleskie wrote:
>> Border/Core/Access is great thinking when your a sales rep for a
>> vendor that sells under power kit.  No reason for it any more.
>
> Hi Jim,
>
> Unfortunately, I have a mix of EOL Cisco gear in my network, along with
> other random custom-built software routers, HP Procurve switches etc.
>
> To be honest, I am very pleased with what I've learnt over the course of
> the last two years with my network re-design/build. In my environment,
> the layered approach is working exceptionally well (and my sales skills
> would have me recommend a different ISP at the drop of a dime if they
> could provide what I couldn't ;)
>
> Primarily, my transition has led me down the BCP 38 path (and it's
> associated techniques/side-effects, specifically automated S/RTBH),
> which aside from IPv6, is the most important thing I believe that I
> could have accomplished during that time.
>
> It would, however, be interesting to learn how the former drawbacks of
> flat networks have evolved, and what new technologies make them
> successful once again.
>
> Thanks,
>
> Steve
>

Re: Location of upstream connections & BGP templates

[jim deleskie]

Absolutely.  I've worked on networks where I'm was amazed on someday
we held it all together, but that is truly when you learn the most.

-jim

On Wed, Feb 17, 2010 at 9:46 PM, Steve Bertrand  wrote:
> On 2010.02.17 20:45, jim deleskie wrote:
>> Of course all designs are limited to the budget you have to build the
>> network :)
>
> Heh, yeah, but it's unbelievable what one can learn on an eBay diet when
> they put their entire heart, soul and dedication into it!
>
> Steve
>

Re: Email Portability Approved by Knesset Committee

[Jim Mercer]

On Mon, Feb 22, 2010 at 11:08:54AM -0500, James Jones wrote:
> On Mon, Feb 22, 2010 at 10:09 AM, Gadi Evron  wrote:
> > According to this proposed bill, when a client transfers to a different ISP
> > the email address will optionally be his to take along, "just like" mobile
> > providers do today with phone numbers.
> 
> Why does this seem like a really bad idea?

actually, i think its a great idea.

now the ISPs will have an actual interest in shutting down and eliminating
SPAM, as it would make little economic sense to be forwarding huge amounts of
email around when the bulk of it is just gonna be discarded anyways.

( i'm half joking )

-- 
Jim Mercerj...@reptiles.org+92 336 520-4504
"I'm Prime Minister of Canada, I live here and I'm going to take a leak."
   - Lester Pearson in 1967, during a meeting between himself and
President Lyndon Johnson, whose Secret Service detail had taken over
Pearson's cottage retreat.  At one point, a Johnson guard asked
Pearson, "Who are you and where are you going?"

Re: 1.0.0.0/8 route from MERIT ?

[Jim Popovitch]

2010/2/24 Alex H. Ryu :
>
> Today I jumped into one of our routers, and I found that 1.0.0.0/8 is
> announced from AS237, which is MERIT.

IIRC, there was an email/wiki/announcement last month about 1/8
undergoing some testing soon.

-Jim P.

Re: ATT / Bellsouth Email Feedback Loop

[Jim Popovitch]

On Thu, Feb 25, 2010 at 11:00, Wade Peacock  wrote:
> Greetings Brain Trust,
>
> We have found ATT to be heavy handed with their email (spam) filtering.
> Without warn all of our mail servers will be denied from delivering email to
> their many domains (att.net, bellsouth.net, etc). They have a removal
> request form (like most other large ISPs) which takes 2 days to process. We
> never find out why the we get listed. We always check as many "email"
> reputation systems and rbl searches to determine why.  Everywhere we
> look we see no evidence of a problem. We have joined other ISP feedback look
> system, (AOL, Yahoo and even Hotmail/Live) which all have helped stop issues
> (comprised accounts, bots, etc) before they get to the point of a
> listing/block.
>
> I have searched and I can not find out definitively whether ATT has or does
> not has a feedback loop system. Anyone out there know?

I know of no ATT FBL system.

If you are getting ATT rejects, then you can enter some info here:
http://worldnet.att.net/general-info/block_admin.html

However, if you are getting blackhole'd you have no recourse, IMHO.

If any AT&T rep wants to step forward, I've know a few people waiting
in the wings with very similar issues.  One even suggested the
blackhole'ing is related to American Idol, as you need to keep your
pipes clean for those revenue generating SMS texts.  ;-)

-Jim P.

Re: Spamcop Blocks Facebook?

[jim deleskie]

If I leave all boxes checked to send mail/notices/app requests to
everyone in my list, or if I give FB my gmail password to pull all my
contacts and send them an invite, its pure @ my request, sure FB is
happy I do it, but it is no way spam. Its like calling 5 ICMP  packets
a DDoS.

-jim

On Thu, Mar 4, 2010 at 3:16 AM, Michelle Sullivan  wrote:
> deles...@gmail.com wrote:
>> Maybe I'm wrong on this,
>
> You are I'm afraid.
>
>> and I'm not a mailadmin anywhere nor have I been or pretended to have been 
>> in the past. But I'm pretty sure FB only sends you mail based on the 
>> prefrences you choose, and I know this is the answer you where given so 
>> mostly a statement. How does that equal spam :)
>>
>
> The default is for everything 'on'.  They will send to any email address
> with notifications and mail regardless of signup and they don't honor
> bounces in any 'email address doesn't work so don't mail it' lists they
> might or might not employ.
>
> Regards,
>
> Michelle
>
>

Re: Spamcop Blocks Facebook?

[jim deleskie]

I'm not going to both on this thread anymore.. waste of time.  Sorry
for the bulk mail/spam generated by my replies to nanog.

I'll stop feeding the trolls now.

-jim

On Thu, Mar 4, 2010 at 3:25 PM, Rich Kulawiec  wrote:
> On Thu, Mar 04, 2010 at 03:16:25PM -0400, jim deleskie wrote:
>> If I leave all boxes checked to send mail/notices/app requests to
>> everyone in my list, or if I give FB my gmail password to pull all my
>> contacts and send them an invite, its pure @ my request, sure FB is
>> happy I do it, but it is no way spam.
>
> This is dead wrong.  You're not authorized to solicit bulk email on behalf
> of third parties: only they are.  In the absence of solicitation from
> the *recipients*, bulk email is spam -- by definition.
>
> ---Rsk
>
>
>

Re: Hughes Network

[Jim Popovitch]

On Thu, May 22, 2008 at 1:39 PM, Jason J. W. Williams
<[EMAIL PROTECTED]> wrote:
> Has anyone else noticed that the [NANOG] prefix has been missing
> intermittently from the list traffic over the last couple of days?

This was planned, and then announced approx 5 days ago.  You are
subscribed to nanog-announce, right? ;-)

-Jim P.

Re: [Nanog-futures] Announce list: Re: Hughes Network

[Jim Popovitch]

On Thu, May 22, 2008 at 9:35 PM, someone wrote:
> Add me to the list of never-saw-that. In addition, I just checked the
> nanog archives, and there isn't an announcement of that type in the
> archives.

Below is the full email, with headers, from Monday.  Hopefully it will
put this issue to rest but somehow I doubt that. ;-)

-Jim P.

Received: by 10.90.53.15 with SMTP id b15cs245753aga;
Mon, 19 May 2008 16:02:48 -0700 (PDT)
Received: by 10.35.10.13 with SMTP id n13mr12798008pyi.30.1211238167720;
Mon, 19 May 2008 16:02:47 -0700 (PDT)
Return-Path: <[EMAIL PROTECTED]>
Received: from s0.nanog.org (s0.nanog.org [198.108.95.20])
by mx.google.com with ESMTP id s59si4779396pyh.13.2008.05.19.16.02.47;
Mon, 19 May 2008 16:02:47 -0700 (PDT)
Received-SPF: pass (google.com: best guess record for domain of
[EMAIL PROTECTED] designates 198.108.95.20 as permitted
sender) client-ip=198.108.95.20;
Authentication-Results: mx.google.com; spf=pass (google.com: best
guess record for domain of [EMAIL PROTECTED] designates
198.108.95.20 as permitted sender)
[EMAIL PROTECTED]
Received: from localhost ([127.0.0.1] helo=s0.nanog.org)
by s0.nanog.org with esmtp (Exim 4.68 (FreeBSD))
(envelope-from <[EMAIL PROTECTED]>)
id 1JyENK-0006V5-UV; Mon, 19 May 2008 23:02:38 +
Received: from ind-iport-1.cisco.com ([64.104.129.195])
by s0.nanog.org with esmtp (Exim 4.68 (FreeBSD))
(envelope-from <[EMAIL PROTECTED]>) id 1JyENI-0006UC-1L
for [EMAIL PROTECTED]; Mon, 19 May 2008 23:02:36 +
X-IronPort-AV: E=Sophos;i="4.27,512,1204482600"; d="scan'208";a="107943185"
Received: from hkg-dkim-1.cisco.com ([10.75.231.161])
by ind-iport-1.cisco.com with ESMTP; 20 May 2008 04:32:33 +0530
Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94])
by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4JN2XlM012133
for <[EMAIL PROTECTED]>; Tue, 20 May 2008 07:02:33 +0800
Received: from Philip-PB.local (sin-vpn-client-20-47.cisco.com [10.68.20.47])
by hkg-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4JN2WVp007247
for <[EMAIL PROTECTED]>; Mon, 19 May 2008 23:02:32 GMT
Message-ID: <[EMAIL PROTECTED]>
Date: Tue, 20 May 2008 09:02:58 +1000
From: Philip Smith <[EMAIL PROTECTED]>
Organization: Cisco Systems
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: [EMAIL PROTECTED]
X-Enigmail-Version: 0.95.6
Authentication-Results: hkg-dkim-1; [EMAIL PROTECTED]; dkim=pass (
sig from cisco.com/hkgdkim1002 verified; );
Subject: [NANOG-announce] email subject tags and footers
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NANOG-Announce 
List-Unsubscribe: <http://mailman.nanog.org/mailman/listinfo/nanog-announce>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://mailman.nanog.org/pipermail/nanog-announce>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Help: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <http://mailman.nanog.org/mailman/listinfo/nanog-announce>,
<mailto:[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: [EMAIL PROTECTED]

Hi everyone,

Following the discussion on nanog-futures, we'd like to let you all know
that the [NANOG] in the subject line and the three extra info lines
mailman appends will be dropped from all future messages going to the
NANOG list, starting in around 24 hours from now.

If any of you have you changed your  e-mail filtering
to depend on the [NANOG] subject tag, please consider this 24 hours
notice to move to another message filtering technique.

Best wishes,

philip
(for the SC)
--


___
NANOG-announce mailing list
[EMAIL PROTECTED]
http://mailman.nanog.org/mailman/listinfo/nanog-announce

Re: [Nanog-futures] Announce list: Re: Hughes Network

[Jim Popovitch]

On Fri, May 23, 2008 at 12:29 PM, Jason J. W. Williams
<[EMAIL PROTECTED]> wrote:
> I'm subscribed to both now. ;-) The advantage to the NANOG subject
> header was obviously it was resilient to e-mail address changes for the
> list. A nice attribute given e-mails now come in from both
> nanog@nanog.org and [EMAIL PROTECTED] addresses. Anyhow, I assume there
> was compelling reason for the change.

There are a plethera of common headers available for filtering,
regardless of To:

-Jim P.

Re: unsubscribe

[Jim Popovitch]

On Tue, May 27, 2008 at 1:55 PM, Scott Weeks <[EMAIL PROTECTED]> wrote:
> Should 10,000 folks change what they do to what you ask because of that?

How many of those 10,000 would need to change, let alone notice a
change?  I suspect the number is less than 10 (that's ten, not ten
thousand).   ;-)

-Jim P.

RE: IOS Rookit: the sky isn't falling (yet)

[Jim Wise]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 29 May 2008, Fred Reimer wrote:

>plaintext (the IOS code) and the hash.  It is not trivial to be able to
>make changes in the code and maintain the same hash value, but there has
>been at least limited success in doing so.

Has there?  My understanding is that constructing a new image to match 
an existing MD5 checksum (vs. constructing two new images with matching 
MD5 checksums) was still not feasible.  Did I miss something?


>It may not be possible to replace the boot ROM, because presumably the new
>hardware would check the ROM code hash before loading it and also
>presumably the ROM code does not have quite as much text messages that can
>be changed to generate the same hash value, thereby bypassing the security
>checks.

This may be an obvious question, but given that the code which verifies an
IOS image would (presumably) be part of the boot ROM, where would you put
the code which verifies the boot ROM?  What does it mean to say `the
hardware' should check the boot ROM?

- -- 
        Jim Wise
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (NetBSD)

iD8DBQFIPrGtq/KRbT0KwbwRArN+AJ0QTuytahkUluOYpCHQ9jw94gNWFQCfTQ5c
2V0w8OO3EnCnJvb3lYh1+sQ=
=o9Ro
-END PGP SIGNATURE-

RE: IOS Rookit: the sky isn't falling (yet)

[Jim Wise]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 29 May 2008, Fred Reimer wrote:

>The code would presumably be run upon boot from a non-flashable source,
>which would run the boot ROM code through a check on the crypto chip and
>only execute it if it passed.  You would not put the code that checks the
>boot ROM on the boot ROM.  The new crypto chip would presumably have the
>initial boot code, which would only be designed to check the boot ROM
>signature and nothing else so presumably would never need to be replaced and
>hence would be designed to be non-flashable.

Doesn't this just push the chicken-and-egg problem up the chain one step?
The ROMMON would be flashable (among other reasons) because the key used to
sign IOS releases should change over the years -- gaining length as cycles
get cheaper, being replaced periodically to prevent use of the same key for
too long, and perhaps being revoked if it should ever be compromised.

If the ROMMON is itself to be verified by a prior, non-flashable ROM, then
all the same arguments would call for making its key-list updatable -- and
given the time-in-service seen by many such devices, any weakness in that
key list would be around for quite some time.

- -- 
        Jim Wise
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (NetBSD)

iD8DBQFIPsdRq/KRbT0KwbwRAkcmAJ4xOBtANHOc+C/fzL+7PvgWnjp76ACfSGUw
43+1Pq3xWS4MagWzdetZ0ws=
=62gJ
-END PGP SIGNATURE-

Large number of DNS probes in last 24 hours

[Jim Wise]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've seen a surprising number of attempted recursive DNS requests 
against unpublished non-recursive DNS servers in the last 24 hours or 
so, many of them obviously probes of some sort (query for "." IN NS, 
eg).

Is anyone else seeing this?  Is it new?  Or did some botnet just reach 
this corner of the IP space?

- -- 
    Jim Wise
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (NetBSD)

iD8DBQFIQDPbq/KRbT0KwbwRAuzVAJ0QRpMw59U7U2qfpEdHOeIt+YVzxgCeLQK4
0HeEYDsVW4VI6ahbjE8xphQ=
=QV9h
-END PGP SIGNATURE-

Re: Large number of DNS probes in last 24 hours

[Jim Wise]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 30 May 2008, Michael Still wrote:

>Jim Wise wrote:
>> I've seen a surprising number of attempted recursive DNS requests 
>> against unpublished non-recursive DNS servers in the last 24 hours or 
>> so, many of them obviously probes of some sort (query for "." IN NS, 
>> eg).
>> 
>> Is anyone else seeing this?  Is it new?  Or did some botnet just reach 
>> this corner of the IP space?
>
>I have seen PlanetLab experiments doing this. What are the originating
>IP addresses?

Three observed source addresses

208.78.169.237
204.11.51.62
194.199.24.101

Source ports are high and non-repeating.  Other than the domain root, 
A-record queries for "google.com" and for hostnames which appear to be 
on the same subnet as the querying host.

- -- 
Jim Wise
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (NetBSD)

iD8DBQFIQNVXq/KRbT0KwbwRAvxDAJ9AuikE/UHx8YvlWIyiL4cdnaVjhwCdGYBI
CTEd5J0L0NCeDnpViMxOPmY=
=W/wp
-END PGP SIGNATURE-

Re: comcast

[Jim Popovitch]

On Thu, Jun 12, 2008 at 10:24 PM, Christian <[EMAIL PROTECTED]> wrote:
> when was the last time you saw this prefix reachable?
>
> i dont see anything announced from comcasts 73.0.0.0/8 allocation within the
> past 2 weeks...

FYI: Internally within Comcast it does route:

$ mtr --report -c 1 73.0.0.1
HOST: blueLoss%   Snt   Last   Avg  Best  Wrst StDev
  1. linksys   0.0% 10.9   0.9   0.9   0.9   0.0
  2. c-24-98-192-1.hsd1.ga.comcas  0.0% 17.3   7.3   7.3   7.3   0.0
  3. ge-2-5-ur01.a2atlanta.ga.atl  0.0% 18.0   8.0   8.0   8.0   0.0
  4. te-9-1-ur02.a2atlanta.ga.atl  0.0% 16.0   6.0   6.0   6.0   0.0
  5. te-9-3-ur01.b0atlanta.ga.atl  0.0% 16.5   6.5   6.5   6.5   0.0
  6. 68.85.232.62  0.0% 16.4   6.4   6.4   6.4   0.0
  7. po-15-ar01.b0atlanta.ga.atla  0.0% 17.6   7.6   7.6   7.6   0.0
  8. te-4-1-cr01.atlanta.ga.cbone  0.0% 19.0   9.0   9.0   9.0   0.0
  9. te-1-1-cr01.charlotte.nc.cbo  0.0% 1   11.8  11.8  11.8  11.8   0.0
 10. te-1-1-cr01.richmond.va.cbon  0.0% 1   19.5  19.5  19.5  19.5   0.0
 11. te-1-1-cr01.mclean.va.cbone.  0.0% 1   24.0  24.0  24.0  24.0   0.0
 12. te-1-1-cr01.philadelphia.pa.  0.0% 1   25.6  25.6  25.6  25.6   0.0
 13. be-40-crs01.401nbroadst.pa.p  0.0% 1   26.5  26.5  26.5  26.5   0.0
 14. be-50-crs01.ivyland.pa.panjd  0.0% 1   28.8  28.8  28.8  28.8   0.0
 15. po-10-ar01.verona.nj.panjde.  0.0% 1   41.7  41.7  41.7  41.7   0.0
 16. po-10-ar01.eatontown.nj.panj  0.0% 1   33.5  33.5  33.5  33.5   0.0
 17. po-10-ur01.middletown.nj.pan  0.0% 1   34.4  34.4  34.4  34.4   0.0
 18. po-10-ur01.burlington.nj.pan  0.0% 1   48.0  48.0  48.0  48.0   0.0

-Jim P.

Re: comcast

[Jim Popovitch]

On Thu, Jun 12, 2008 at 11:34 PM, Martin Hannigan <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 12, 2008 at 10:35 PM, Jim Popovitch <[EMAIL PROTECTED]> wrote:
>
>>  18. po-10-ur01.burlington.nj.pan  0.0% 1   48.0  48.0  48.0  48.0   0.0
>
>  23   114 ms   122 ms   113 ms  ge-0-1-ubr02.pittsburg.ca.sfba.comcast.net 
> [68.8
> 7.197.22]
>
> Für eine Weile hatten wir Zugang durch eine Hong Kong basiert Piraten-Netzwerk

Yeah, I've saw similar in traces a few days back, I wondered wtf.

-Jim P.

Re: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)

[Jim Popovitch]

On Sun, Jun 22, 2008 at 12:17 PM, Paul Vixie <[EMAIL PROTECTED]> wrote:
> so, i'm not whining, just pointing out that this is a sea change, the end of 
> an era.

I think that era ended when RBLs became so difficult to maintain
without hour-by-hour effort.   The sad thing is that there is no
inverse-RBLs and MTAs that work straight forward with them.   In
todays, and tomorrows, world there needs to be a process of vetting
inbound SMTP connections.   I would much rather deal with a process
that requires "proof of need to participate" rather than having wide
open doors and windows and only being able to use a fly swatter.   The
problem with an maintaining an inverse-RBL is that it would require a
centralized and reliable entity, not just one or two joe schmoes

-Jim P.

ICANN opens up Pandora's Box of new TLDs

[Jim Popovitch]

Two years ago I posed the question here about the need for TLDs
(http://www.mcabee.org/lists/nanog/May-06/msg00110.html).
I summerizsed that companies IP (Intellectual Property) guidelines
would never allow domain.org to exist if they owned domain.com
(ibm.org vrs ibm.com).I felt that TLDs really represented a
monetary harvesting scheme as every new TLD forced companies to "pay
for yet another domain name" (slowly milking businesses).   At that
time several knowledgeable folks commented that TLDs  were necessary
in the beginning due to the need to distribute queries.   Now it
seems, ICANN has decided to add a new paradigm :-)   How will a TLD
like .ibm be handled now, and how is this different than what I
proposed in 2006?

-Jim P.

Re: ICANN opens up Pandora's Box of new TLDs

[Jim Popovitch]

On Thu, Jun 26, 2008 at 10:49 PM, Rich Kulawiec <[EMAIL PROTECTED]> wrote:
> So the outcome of this is inevitable: expense, litigation, hassle,
> spam, abuse, and oh-by-the-way massive profits for registrars, which
> had nothing at all to do with ICANN's decision.  Of course not.

Perhaps this is straying into OT land... (but I must push the envelope!) ;-)

Is there any "full disclosure" clause in ICANN member contracts such
that gifts from, or stock in, a Registrar would be declared?

-Jim P.

Re: ICANN opens up Pandora's Box of new TLDs

[Jim Shankland]

Randy Bush wrote:

this is analogous to the gossip that most spam comes from china, asia,
nigeria, or whomever we like to be xenophobic or racist about this week.
measurement shows the united states to be the largest single source of spam.


Because it's Friday, I checked the last few weeks or so of logs from
my personal mail server (located in the US), and broke the list of
unique IP addresses rejected by zen.spamhaus.org up by registry:

49.2%   RIPE
22.2%   LACNIC
13.8%   ARIN
13.5%   APNIC
 1.3%   Afrinic

ARIN's share may be slightly overstated, as it includes most of
the legacy blocks.

For what it's worth 

Jim Shankland

Re: ICANN opens up Pandora's Box of new TLDs

[Jim Shankland]

Phil Regnauld wrote:

Requirement ?  What requirement ?  There's no requirement for
reverse DNS for email in any RFC.


As a practical matter, I've found that sending out email from a
host without rDNS doesn't work:  too many sites bounce the mail.

It will not come as news to anyone on this list that the world
of SMTP is hardly well-defined or well-regulated in practice.
Like Rowlf the dog, we can't live with it, we can't live without
it, but we're stuck until something better comes along:

http://www.youtube.com/watch?v=1vvV9LjBsNw

Jim Shankland

Re: Mail Server best practices - was: Pandora's Box of new TLDs

[Jim Popovitch]

On Sat, Jun 28, 2008 at 2:21 PM, Frank Bulk - iNAME <[EMAIL PROTECTED]> wrote:
> FB> The point is that those are able to create a valid rDNS entry likely
> have more control of their infrastructure than those who don't.  You must
> admit, if you can't get a proper rDNS entry created for your domain, what
> does that say about your ability to control your infrastructure?

And to that point, a valid rDNS entry can easily be removed by the
netblock holder at smal co-lo facility.  This is an easy, although not
widely used enough, means for co-lo providers to retain control over
leased (mail) servers without worrying about the legal issues with
pre-maturely taking a customer offline.  I've never seen a posted
service delivery statement that guaranteed PTRs.  In fact, IMHO, PTRs
are a courtesy from the netblock owner, not a given.

-Jim P.

Re: what problem are we solving? (was Re: ICANN opens up Pandora'sBox of

[Jim Popovitch]

On Sun, Jun 29, 2008 at 1:21 PM, Peter Beckman <[EMAIL PROTECTED]> wrote:
> Let the search engines organize the web, not DNS.

OK, (assuming you believe that), why keep dns around.  Why not go back
to just IP addrs and hosts files for those that need them.

-Jim P.

Re: tacid.org

[Jim Popovitch]

On Sun, Jul 6, 2008 at 11:09 AM, Nick Shank <[EMAIL PROTECTED]> wrote:
> After doing a bit of digging, it doesn't appear the any of the tacid.org 
> ip-space is blacklisted (one less
> battle I have to fight). Fortune 100? Nope. Just a small non-profit org in 
> Tacoma, WA, that got their
> exchange box rooted. I'm still trying to figure out the full extent of the 
> damage done, but this point,
> I believe 99.7% of the outbound mail is legit. In-bound is another story 
> entirely, but that's my own
> private hell to deal with.

This in no way is a negative assumption on your skills.   There is
some important information missing from the above details.  You wrote
that your Exchange box was rooted, but you didn't indicate what you
did to resolve that.  I'm not looking for the details of what you did,
just an overall statement about how you rectified it.  You also
indicate that you are still assessing the full extent of the damage,
is that to the Exchange box or to the IP space?

Thanks,

-Jim P.

Re: tacid.org

[Jim Popovitch]

On Sun, Jul 6, 2008 at 3:55 PM, Nick Shank <[EMAIL PROTECTED]> wrote:
> Jim,
>  ATM I have exchange set to dis-allow outbound mail

Hi Nick,

I (personally) don't think that is enough.  If the box was rooted,
there could be bots (i.e. other processes) sending outbound email.
Those processes could be persistent or periodic, and they could be
additional services or sub-processes of known-good services.  Further,
the bots could be dynamically loaded via on-box applications (i.e.
Internet Explorer, Firefox, etc.)

You would need an off-box firewall to successfully block outbound SMTP
connections.  With most, if not all, rooted boxs there really is no
safe way of securing it.  Your best path forward is to (IMHO) buy an
new harddrive and start from scratch, manually copying only known-good
files to the new drive, preferably using an intermediate box to virus
scan each moved file.

Best wishes,

-Jim P.

Re: https (was: Re: Exploit for DNS Cache Poisoning - RELEASED)

[Jim Popovitch]

On Thu, Jul 24, 2008 at 11:24 PM, Hank Nussbacher <[EMAIL PROTECTED]> wrote:
> I wish Yahoo and Hotmail even had the ability of *reading* email via https:
> http://www.interall.co.il/hotmail-yahoo-https.html

Hah!  It was only a year ago that Yahoo even added SSL capabilities
for login.  Six months ago they added POP3S.

-Jim P.