Re: DNS Attacks

[Ken Gilmour]

On Feb 18, 2012 10:24 PM, "Robert Bonomi"  wrote:
>
> Even better, nat to a 'bogon' DNS server -- one that -- regardless of the
> query -- returns the address of a dedicated machine on your network set up
> especially for this purpose.

What happens when the client sends a POST from a cached page on the end
user's machine? E.g. if they post login credentials. Of course, they'll get
the error page, but then you have confidential data in your logs and now
you have to protect highly confidential info, at least if you're in europe.

Re: DNS Attacks

[Patrick W. Gilmore]

On Feb 19, 2012, at 10:59, Ken Gilmour  wrote:
> On Feb 18, 2012 10:24 PM, "Robert Bonomi"  wrote:
>> 
>> Even better, nat to a 'bogon' DNS server -- one that -- regardless of the
>> query -- returns the address of a dedicated machine on your network set up
>> especially for this purpose.
> 
> What happens when the client sends a POST from a cached page on the end
> user's machine? E.g. if they post login credentials. Of course, they'll get
> the error page, but then you have confidential data in your logs and now
> you have to protect highly confidential info, at least if you're in europe.

It is possible to configure the web server not to log POSTed info.

-- 
TTFN,
patrick

Re: DNS Attacks

[Jeroen Massar]

On 2012-02-19 12:59 , Patrick W. Gilmore wrote:
> On Feb 19, 2012, at 10:59, Ken Gilmour  wrote:
>> On Feb 18, 2012 10:24 PM, "Robert Bonomi"  wrote:
>>>
>>> Even better, nat to a 'bogon' DNS server -- one that -- regardless of the
>>> query -- returns the address of a dedicated machine on your network set up
>>> especially for this purpose.
>>
>> What happens when the client sends a POST from a cached page on the end
>> user's machine? E.g. if they post login credentials. Of course, they'll get
>> the error page, but then you have confidential data in your logs and now
>> you have to protect highly confidential info, at least if you're in europe.
> 
> It is possible to configure the web server not to log POSTed info.

Per default most webservers (Apache, nginx, etc) won't log POST
variables, GET variables will be logged (as they are part of the query)
but those should not contain any PII.

Greets,
 Jeroen

Re: DNS Attacks

[Valdis . Kletnieks]

On Sun, 19 Feb 2012 13:02:01 +0100, Jeroen Massar said:

> Per default most webservers (Apache, nginx, etc) won't log POST
> variables, GET variables will be logged (as they are part of the query)
> but those should not contain any PII.

Right. They shouldn't.  But the security mailing lists have lots of
counter-examples from clue-challenged web developers.. Plan your logging
strategy accordingly (is there any safe answer here other than "disable
logging" or "log only timestamp and source IP"?)



pgpu0o5DbjTlJ.pgp
Description: PGP signature

CLEC in NJ for Sprint/Centurytel

[chris]

Hello,

We use DSL as a backup for some of our client sites where there is no
better alternative. I am looking for a preferably facilities based CLEC in
NJ who can provide us with DSL in sprint/centurytel territories. If anyone
has any recommendations for companies which can do this, experiences, etc
it would be great.

Thanks,
chris

Re: DNS Attacks

[Robert Bonomi]

> From ken.gilm...@gmail.com  Sun Feb 19 05:04:39 2012
> Date: Sun, 19 Feb 2012 11:59:37 +0100
> Subject: Re: DNS Attacks
> From: Ken Gilmour 
> To: Robert Bonomi 
> Cc: nanog@nanog.org
>
> On Feb 18, 2012 10:24 PM, "Robert Bonomi"  wrote:
> >
> > Even better, nat to a 'bogon' DNS server -- one that -- regardless of the
> > query -- returns the address of a dedicated machine on your network set up
> > especially for this purpose.
>
> What happens when the client sends a POST from a cached page on the end
> user's machine? E.g. if they post login credentials. Of course, they'll get
> the error page, but then you have confidential data in your logs and now
> you have to protect highly confidential info, at least if you're in europe.
>

*WHAT* 'confidential data' in which logs?   

The aforementioned dedicated machine isn't a real web-server, or a real
'any other' server -- it is solely a special-purpose application machine,
When you connect to it on say, port 80, it doesn't log anything from the 
port -- it just logs (1) the timestamp, and (2) the connecting IP address 
(and _nothing_ else); then it copies out a previously prepared static file,
and disconnects.

You build a separae app that reads that logfile, matches IP ddress/timestamp
to a customer account, and feeds a message into the 'customer records' system
that this customer -has- been notified of this problem, and when, in case 
they call for support.

If one is 'really' paranoid, the 'logfile' can be implemented as a 'pipe'
between the processes, so that the data never hits disk in the first place. ;)

I've got proof-of-concept code for a single program that handles HTTP (port
80), SMTP (port 25 and port 587), POP3 (port 110), IMAP2 & 4 (port 143), IMAP3
(port 220), TELNET (port 23), FTP (port 21), and NNTP (port 119), so far.   
I'm planing to add IRC, and various SSL-based protocols as well.

Re: public scalable vpn?

[Steven Bellovin]

On Feb 18, 2012, at 6:51 PM, George Bonser wrote:

>> academics in ontario are gonna need a scalable vpn service until they
>> find jobs elsewhere.
>> 
>> http://www.cautbulletin.ca/en_article.asp?SectionID=1386&SectionName=Ne
>> ws&VolID=336&VolumeName=No%202&VolumeStartDate=2/10/2012&EditionID=36&E
>> ditionName=Vol%2059&EditionStartDate=1/19/2012&ArticleID=3400
>> 
>> i can only handle a dozen or so.  anyone running anything at scale?
>> 
>> randy
> 
> "The agreement reached last month with the licensing agency includes 
> provisions defining e-mailing hyperlinks as equivalent to photocopying a 
> document"
> 
> I certainly hope that is some politicized hype printed in that article and 
> not real.  That is absolutely idiotic on the face of it.  When I have seen 
> stuff like this printed in the past it has generally been over the top 
> catastrophizing of an issue in order to inflame emotions.  I sure hope that's 
> the case here.  Otherwise my impression of Canadians has sunk to a new low.  
> Why would it be in anyone's interest to sign such an agreement?

It seems to be real -- see 
http://communications.uwo.ca/western_news/stories/2012/February/copyright_deal_struck.html

I asked a Canadian friend of mine (who has serious privacy and security 
expertise) about it.  She said "Yes - we were discussing this vile decision in 
my Technopolicy law class...  I have no idea what they were thinking! Idiots."

--Steve Bellovin, https://www.cs.columbia.edu/~smb

Re: Colo Vending Machine

[John Curran]

On Feb 18, 2012, at 1:55 PM, Astrodog wrote:
> On Fri, Feb 17, 2012 at 7:13 PM, Gary Buhrmaster
>  wrote:
>> On Sat, Feb 18, 2012 at 01:02, George Herbert  
>> wrote:
>> 
 Will IANA accept netblock transfers as an exchange medium for
 datacenter goodies vending machine payments? ...  ;-)
>>> 
>>> Joking while busy discouraged.  s/IANA/ARIN/d'oh
>> 
>> I suspect ARIN would follow its policy to recognize
>> any transfer and update its records as long as the
>> needs assessment was successfully completed,
>> but any compensation between the seller and
>> buyer of the resource is not part of the ARIN process.
>> 
>> (This is a (bad?) joke reference to a currently
>> ongoing discussion on the ARIN PPML list).
> 
> Hah. So, this should work, provided both entities are on the STSL then.

"Sure..."  ;-)

That means you'd want about $2K worth of gear because of the existing /24 
minimum, in addition to vending machine able to explain why it needs the 
address space.   

Have fun,
/John

p.s. A /16 might be about right for a pack of 100G SMF CFP modules...

Dynadot DNS acting up?

[Chris]

Anyone noticing issues with Dynadot (site is down) and Dynadot related
domain names where you are using their DNS servers?

-- 
--C

"The dumber people think you are, the more surprised they're going to
be when you kill them." - Sir William Clayton

Re: Colo Vending Machine

[Astrodog]

On Sun, Feb 19, 2012 at 11:21 AM, John Curran  wrote:
> On Feb 18, 2012, at 1:55 PM, Astrodog wrote:
>> On Fri, Feb 17, 2012 at 7:13 PM, Gary Buhrmaster
>>  wrote:
>>> On Sat, Feb 18, 2012 at 01:02, George Herbert  
>>> wrote:
>>> 
> Will IANA accept netblock transfers as an exchange medium for
> datacenter goodies vending machine payments? ...  ;-)

 Joking while busy discouraged.  s/IANA/ARIN/d'oh
>>>
>>> I suspect ARIN would follow its policy to recognize
>>> any transfer and update its records as long as the
>>> needs assessment was successfully completed,
>>> but any compensation between the seller and
>>> buyer of the resource is not part of the ARIN process.
>>>
>>> (This is a (bad?) joke reference to a currently
>>> ongoing discussion on the ARIN PPML list).
>>
>> Hah. So, this should work, provided both entities are on the STSL then.
>
> "Sure..."  ;-)
>
> That means you'd want about $2K worth of gear because of the existing /24
> minimum, in addition to vending machine able to explain why it needs the
> address space.
>
> Have fun,
> /John
>
> p.s. A /16 might be about right for a pack of 100G SMF CFP modules...
>

This gives me an idea. The vending machine could also sell hosting.
Sometimes, the box just won't come back to life and you need somewhere
to stuff the data. *grin*

(Actually, based on a few of my DC visits, there are times where I'd
have gladly shelled out $2k for a small baggie of screws.)

--- Harrison

Re: Common operational misconceptions

[Owen DeLong]

On Feb 18, 2012, at 3:31 AM, Masataka Ohta wrote:

> David Barak wrote:
> 
>>> From: Owen DeLong o...@delong.com
>> 
>>> Sigh... NAT is a horrible hack that served us all too well in
> >> address conservation. Beyond that, it is merely a source of pain.
>> 
>> I understand why you say that - NAT did yeoman's work in address
> > conservation. However, it also enabled (yes, really) lots of
> > topologies and approaches which are *not* designed upon the
> > end-to-end model. Some of these approaches have found their way
> > into business proceses.
> 
> I'm afraid both of you don't try to understand why NAT was
> harmful to destroy the end to end transparency nor the end
> to end argument presented in the original paper by Saltezer
> et. al:
> 
>  The function in question can completely and correctly be
>  implemented only with the knowledge and help of the application
>  standing at the end points of the communication system. Therefore,
>  providing that questioned function as a feature of the
>  communication system itself is not possible.
> 
> While plain NAT, which actively hide itself from end systems,
> which means there can be no "knowledge and help of the
> application" expected, is very harmful to the end to end
> transparency, it is possible to entirely neutralize the
> harmful effects, by let NAT boxes ask help end systems.
> 
>> An argument you and others have made many times boils down
> > to "but if we never had NAT, think how much better it
> > would be!"
> 
> The reality is much better that NAT is not so harmful if NAT
> clients and gateways are designed properly to be able to
> reverse the harmful translations by NAT gateways.
> 
> I have running code to make the reverse translations, with
> which protocols such as ftp with PORT commands are working.
> 
>   Masataka Ohta


No, I think you do not understand...

I have a NAT gateway with a single public address.

I have 15 FTP servers and 22 web servers behind it.

I want people to be able to go to ftp:// and/or http:// for 
each of them.

Please explain to me how your code solves this problem?

Yeah, thought so.

Owen

Re: facebook.com DNS not found 20120218 2125 UTC

[Jeff Kell]

On 2/18/2012 4:32 PM, Everett Batey wrote:
> facebook.com DNS not found 20120218 2125 UTC
> Is there any outage information for DNS for  facebook.com / www.facebook.com
>  ?
>   "Oops! Google Chrome could not find www.facebook.com"

I have had two reports of "can't get to facebook" from campus today, not
exactly from 3rd-tier helpdesk techs mind you, but a reasonably
reputable source.  "Traceroute stops at 127.0.0.1" (yeah, I know).

Works fine from campus for me, and they say the machine does "nslookup"
a Facebook CDN provider IP (69.171.234.96).  They can go anywhere else,
no problem.  Verified they have our DHCP server and internal recursive
DNS servers so it's not an issue at that level.

I'm "ONLY" bringing this up as my spidey-sense is wondering if there is
some facebook-captive malware or browser plugin floating about? 

Ring any bells?

If nothing else comes in I'm going to write it off as a Sunday evening
hallucination and check it again tomorrow :)

Jeff

Re: Common operational misconceptions

[Joe Greco]

> > I have running code to make the reverse translations, with
> > which protocols such as ftp with PORT commands are working.
> 
> No, I think you do not understand...
> 
> I have a NAT gateway with a single public address.
> 
> I have 15 FTP servers and 22 web servers behind it.
> 
> I want people to be able to go to ftp:// and/or =
> http:// for each of them.

Owen,

Your suggestion here would set many "security experts" heads on fire.

Whatever will they do when NAT doesn't make such things virtually
impossible?

:-)

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: Common operational misconceptions

[Jimmy Hess]

On Sun, Feb 19, 2012 at 6:24 PM, Owen DeLong  wrote:
> I have 15 FTP servers and 22 web servers behind it.
> I want people to be able to go to ftp:// and/or http:// 
> for each of them.

For HTTP;  You put a device on that one IP that will accept each TCP
connection,  await the SNI or Host  header from the client,   and then
make/forward  the connection to a proper server for that hostname.
The public IP address belongs to the FTP/HTTP  "service"  instead of
belonging to a server.


For FTP,  send to a desired FTP server based on the login username or
otherwise make a SRV record for the  _ftp  service for each hostname,
 and   set aside a TCP port for each FTP service's control connection.

The   ftp://user@   approach  or the
ftp://user@//  is  probably more convenient
than ftp://:<1234>, since many clients do not support SRV
records.

The problem is with the FTP protocol not supporting virtual hosting,
though;  this missing FTP feature is not a NAT problem per se.

The VHOST problem was solved with HTTP a long time ago.
It's just that FTP is a lot less popular / fell into some disuse,  so
the deficiency  (lack of virtual hosting support)   was  never
corrected -- and the protocol hasn't had a single update in a long
time.

So you'll have to have a workaround to do 15 FTP servers with one
global IP,  because your circumstance is so unusual,  that's just
life.

--
-JH

Re: facebook.com DNS not found 20120218 2125 UTC

[Callahan Warlick]

Please feel free to unicast me if you ever see any reproducible issues.

-Callahan

On Sun, Feb 19, 2012 at 5:01 PM, Jeff Kell  wrote:
> On 2/18/2012 4:32 PM, Everett Batey wrote:
>> facebook.com DNS not found 20120218 2125 UTC
>> Is there any outage information for DNS for  facebook.com / www.facebook.com
>>  ?
>>   "Oops! Google Chrome could not find www.facebook.com"
>
> I have had two reports of "can't get to facebook" from campus today, not
> exactly from 3rd-tier helpdesk techs mind you, but a reasonably
> reputable source.  "Traceroute stops at 127.0.0.1" (yeah, I know).
>
> Works fine from campus for me, and they say the machine does "nslookup"
> a Facebook CDN provider IP (69.171.234.96).  They can go anywhere else,
> no problem.  Verified they have our DHCP server and internal recursive
> DNS servers so it's not an issue at that level.
>
> I'm "ONLY" bringing this up as my spidey-sense is wondering if there is
> some facebook-captive malware or browser plugin floating about?
>
> Ring any bells?
>
> If nothing else comes in I'm going to write it off as a Sunday evening
> hallucination and check it again tomorrow :)
>
> Jeff
>

Re: Common operational misconceptions

[Mark Andrews]

In message <201202200107.q1k17w5l000...@aurora.sol.net>, Joe Greco writes:
> > > I have running code to make the reverse translations, with
> > > which protocols such as ftp with PORT commands are working.
> > 
> > No, I think you do not understand...
> > 
> > I have a NAT gateway with a single public address.
> > 
> > I have 15 FTP servers and 22 web servers behind it.
> > 
> > I want people to be able to go to ftp:// and/or =
> > http:// for each of them.
> 
> Owen,
> 
> Your suggestion here would set many "security experts" heads on fire.
> 
> Whatever will they do when NAT doesn't make such things virtually
> impossible?
> 
> :-)

Time to write "How to use SRV with FTP".  CGN is going to push
the extension of a whole lot of protocols.

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

Re: Common operational misconceptions

[Octavio Alvarez]

On Wed, 15 Feb 2012 12:47:15 -0800, John Kristoff  wrote:


I have a handful of common misconceptions that I'd put on a top 10 list,
but I'd like to solicit from this community what it considers to be the
most annoying and common operational misconceptions future operators
often come at you with.


The idea that "the more access-points, the better our WiFi".

Oh, and the use of RJ45 for the unconfigured 8P8C, but this is not that
annoying.

Cheers.

Re: Common operational misconceptions

[Karl Auer]

On Sun, 2012-02-19 at 19:09 -0600, Jimmy Hess wrote:
> For HTTP;  You put a device on that one IP that will accept each TCP
> connection,  await the SNI or Host  header from the client,   and then
> make/forward  the connection to a proper server for that hostname.

So you need an extra device to work around NAT. Or you have to build
extra smarts into existing devices to work around NAT. There is a
pattern here...
 
> For FTP,  send to a desired FTP server based on the login username or
> otherwise make a SRV record for the  _ftp  service for each hostname,
>  and   set aside a TCP port for each FTP service's control connection.

So NAT does indeed prevent the scenario Owen outlined.

It does not make sense to make that the application's fault. If you have
to build NAT-awareness (even indirectly, as in SRV-awareness) into every
application, then you've lost the game and it might be time to realise
that NAT is the problem, not all the applications.

> The problem is with the FTP protocol not supporting virtual hosting,
> though;  this missing FTP feature is not a NAT problem per se.

I'm not sure I agree with that, see above. And while virtual hosting may
be a Good Thing for various other reasons, it seems to me that if it is
required with NAT and is not required without NAT, then it is most
certainly "the fault of NAT" that it is required.

Regards, K.

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

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687


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

Re: Common operational misconceptions

[Masataka Ohta]

Owen DeLong wrote:

>> I have running code to make the reverse translations, with
>> which protocols such as ftp with PORT commands are working.

> No, I think you do not understand...

How can't I understand several minor issues with the running code.

> I have 15 FTP servers and 22 web servers behind it.
> I want people to be able to go to ftp://  and/or http://  
> for each of them.
> Please explain to me how your code solves this problem?

See

   draft-ohta-urlsrv-00.txt

   DNS SRV RRs of a domain implicitly specify servers and port numbers
   corresponding to the domain.

   By combining URLs and SRV RRs, no port numbers have to be specified
   explicitly in URLs, even if non-default port numbers are used, which
   makes URLs more concise for port based virtual and real hosting,
   where port based real hosting means that multiple servers sharing an
   IP address are distinguished by port numbers to give service for
   different URLs, which is the case for port forwarded servers behind
   NAT and servers with realm specific IP.

> Yeah, thought so.

The draft has been available since September 29, 2011.

Masataka Ohta

Re: Common operational misconceptions

[Andrew Jones]

On Mon, 20 Feb 2012 11:17:32 +0900, Masataka Ohta
 wrote:
>draft-ohta-urlsrv-00.txt
> 
>DNS SRV RRs of a domain implicitly specify servers and port numbers
>corresponding to the domain.
> 
>By combining URLs and SRV RRs, no port numbers have to be specified
>explicitly in URLs, even if non-default port numbers are used, which
>makes URLs more concise for port based virtual and real hosting,
>where port based real hosting means that multiple servers sharing an
>IP address are distinguished by port numbers to give service for
>different URLs, which is the case for port forwarded servers behind
>NAT and servers with realm specific IP.
> 

It seems to me that this will create all sorts of headaches for firewall
ALGs. Rather than just passing port 21/tcp traffic to the FTP ALG for
example, the devices would need to inspect traffic on all ports and perform
DPI. This is not as much of a problem on the firewall protecting the
servers (you know what ports to inspect), but will require a lot more
processing power on the client-side NAT firewall.

Jonesy

Re: Common operational misconceptions

[Jimmy Hess]

On Sun, Feb 19, 2012 at 10:09 PM, Andrew Jones  wrote:
> On Mon, 20 Feb 2012 11:17:32 +0900, Masataka Ohta
> It seems to me that this will create all sorts of headaches for firewall
> ALGs. Rather than just passing port 21/tcp traffic to the FTP ALG for
> example, the devices would need to inspect traffic on all ports and perform
[snip]

That doesn't work when the FTP control connection is encrypted using SSL.
Layer 4  Firewall devices should not be expecting to intercept FTP
traffic and make decisions based on the application layer contents of
the traffic.

I would suggest a requirement that FTP clients utilizing SRV records
to access FTP on an alternate port MUST utilize Firewall-Friendly FTP
as described by RFC1579.

Each FTP server can then be assigned its own port range, or the FTP
server can be configured to notify the Firewall device which ports to
forward using UpNP or a NAT traversal protocol such as STUN, and the
Firewall device can be configured  to forward the appropriate range of
ports  to the correct server.

--
-JH

Re: Colo Vending Machine

[Jimmy Hess]

On Sun, Feb 19, 2012 at 3:05 PM, Astrodog  wrote:
> This gives me an idea. The vending machine could also sell hosting.
> Sometimes, the box just won't come back to life and you need somewhere
> to stuff the data. *grin*

How about a vending machine, where you insert a hard drive, swipe your card,
and it either gets vaulted to S3 or an EC2 intance is spawned on the
cloud, and the data on the drive becomes the instance's boot media and
gets streamed to the instance storage over a 10-gigabit connection
from the vending machine,  until all the data's uploaded.

That solves the problem of end users getting their data to the hosting
provider quickly, with no need to stress out their low-speed WAN.

--
-JH

Re: Colo Vending Machine

[Anurag Bhatia]

Nice idea of future! :)


Btw as side question - I heard transfer rates from S3 are capped badly.
Something like 5-10Mbps. Is that true? Anyone of you ever came across such
cap?

On Mon, Feb 20, 2012 at 11:08 AM, Jimmy Hess  wrote:

> On Sun, Feb 19, 2012 at 3:05 PM, Astrodog  wrote:
> > This gives me an idea. The vending machine could also sell hosting.
> > Sometimes, the box just won't come back to life and you need somewhere
> > to stuff the data. *grin*
>
> How about a vending machine, where you insert a hard drive, swipe your
> card,
> and it either gets vaulted to S3 or an EC2 intance is spawned on the
> cloud, and the data on the drive becomes the instance's boot media and
> gets streamed to the instance storage over a 10-gigabit connection
> from the vending machine,  until all the data's uploaded.
>
> That solves the problem of end users getting their data to the hosting
> provider quickly, with no need to stress out their low-speed WAN.
>
> --
> -JH
>
>


-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Twitter: @anurag_bhatia 
Linkedin: http://linkedin.anuragbhatia.com

Re: Colo Vending Machine

[Mike Lyon]

My rsync appeared to be running at 20+ Mbps to S3 last night...

Sent from my iPhone

On Feb 19, 2012, at 21:41, Anurag Bhatia  wrote:

> Nice idea of future! :)
>
>
> Btw as side question - I heard transfer rates from S3 are capped badly.
> Something like 5-10Mbps. Is that true? Anyone of you ever came across such
> cap?
>
> On Mon, Feb 20, 2012 at 11:08 AM, Jimmy Hess  wrote:
>
>> On Sun, Feb 19, 2012 at 3:05 PM, Astrodog  wrote:
>>> This gives me an idea. The vending machine could also sell hosting.
>>> Sometimes, the box just won't come back to life and you need somewhere
>>> to stuff the data. *grin*
>>
>> How about a vending machine, where you insert a hard drive, swipe your
>> card,
>> and it either gets vaulted to S3 or an EC2 intance is spawned on the
>> cloud, and the data on the drive becomes the instance's boot media and
>> gets streamed to the instance storage over a 10-gigabit connection
>> from the vending machine,  until all the data's uploaded.
>>
>> That solves the problem of end users getting their data to the hosting
>> provider quickly, with no need to stress out their low-speed WAN.
>>
>> --
>> -JH
>>
>>
>
>
> --
>
> Anurag Bhatia
> anuragbhatia.com
> or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
> network!
>
> Twitter: @anurag_bhatia 
> Linkedin: http://linkedin.anuragbhatia.com

Re: Common operational misconceptions

[Masataka Ohta]

George Bonser wrote:

>> It is seemingly working well means there is not much PMTU changes,
>> which means we had better assumes some PMTU (1280B, for example) and
>> use it without PMTUD.

> It depends on the OS and the method being used.  If you set the
> option to "2" on Linux, it will do MTU probing constantly and
> react to MTU changes.

It actually does nothing.

Given the following statements in the RFC:

   An initial eff_pmtu of 1400 bytes might
   be a good compromise because it would be safe for nearly all tunnels
   over all common networking gear, and yet close to the optimal MTU for
   the majority of paths in the Internet today.

and

   Each Packetization Layer MUST determine when probing has converged,
   that is, when the probe size range is small enough that further
   probing is no longer worth its cost.  When probing has converged, a

the hosts are keep assuming PMTU of 1400B and if local MTU
is 1500B or less, no discovery is performed because "the
probe size range is small enough".

> Also, the MTU for a given path only "lives" for 5 minutes anyway
> (by default) and is "rediscovered" with Linux.   (value in
> /proc/sys/net/ipv4/route/mtu_expires) but other operating
>  systems may behave in other ways.

See above. Rediscovery with initial eff_pmtu of 1400B and
search_high of 1500B immediately terminates without any
probe packets sent.

Masataka Ohta

Re: DNS Attacks

[Ken Gilmour]

--
Sent from my smart phone. Please excuse my brevity
On Feb 19, 2012 4:10 p.m., "Robert Bonomi"  wrote:
>
> > From ken.gilm...@gmail.com  Sun Feb 19 05:04:39 2012
> > Date: Sun, 19 Feb 2012 11:59:37 +0100
> > Subject: Re: DNS Attacks
> > From: Ken Gilmour 
> > To: Robert Bonomi 
> > Cc: nanog@nanog.org
> >
> > On Feb 18, 2012 10:24 PM, "Robert Bonomi" 
wrote:
> > >
> > > Even better, nat to a 'bogon' DNS server -- one that -- regardless of
the
> > > query -- returns the address of a dedicated machine on your network
set up
> > > especially for this purpose.
> >
> > What happens when the client sends a POST from a cached page on the end
> > user's machine? E.g. if they post login credentials. Of course, they'll
get
> > the error page, but then you have confidential data in your logs and now
> > you have to protect highly confidential info, at least if you're in
europe.
> >
>
> *WHAT* 'confidential data' in which logs?   
>
> The aforementioned dedicated machine isn't a real web-server, or a real
> 'any other' server -- it is solely a special-purpose application machine,
> When you connect to it on say, port 80, it doesn't log anything from the
> port -- it just logs (1) the timestamp, and (2) the connecting IP address
> (and _nothing_ else); then it copies out a previously prepared static
file,
> and disconnects.
>
> You build a separae app that reads that logfile, matches IP
ddress/timestamp
> to a customer account, and feeds a message into the 'customer records'
system
> that this customer -has- been notified of this problem, and when, in case
> they call for support.
>
> If one is 'really' paranoid, the 'logfile' can be implemented as a 'pipe'
> between the processes, so that the data never hits disk in the first
place. ;)
>
> I've got proof-of-concept code for a single program that handles HTTP
(port
> 80), SMTP (port 25 and port 587), POP3 (port 110), IMAP2 & 4 (port 143),
IMAP3
> (port 220), TELNET (port 23), FTP (port 21), and NNTP (port 119), so far.
> I'm planing to add IRC, and various SSL-based protocols as well.
>

So you're suggesting that the client sends a DNS request to one of the sink
holes, which is intercepted by an appliance via some sort of NAT and then
dropped? That's also illegal in Europe. You are denying users the right to
information.

Using a redirect to some sort of Web server (a weird sort of DNS poisoning)
will at least inform a user that they're infected. But then that opens
another can of worms. I am imagining some sort of Facebook style "free
notification system" free to what extent? It also trains users to accept
foreign security advice aka fake AV warnings.