Re: The Next Big Thing: Named-Data Networking

[Masataka Ohta]

Barry Shein wrote:

> The idea is very simple, each site would be responsible for their own
> domain and to respond to simple remote requests for name to ip address
> mappings or back again.

Wrong. DNS is not that simple.

Domains and sites have, in general, independent topology
that sites can not be responsible for domains.

Perhaps, your misunderstanding is commonly shared by those
who believe in NDN, though they might think there are
negligible number of exceptions.

Then, data, mostly, could be routed based on name hierarchy,
which scales well.

The reality, however, is that exceptions are everywhere
and we need something like DNS to translate names into
something scalably routable, that is, hierarchical
addresses.

Masataka Ohta

Re: The Next Big Thing: Named-Data Networking

[Matthias Waehlisch]

On Fri, 5 Sep 2014, Sander Steffann wrote:

> Well, you don't need addresses for clients, just for content... From 
> the architecture page at http://named-data.net/project/archoverview/:
>
> "Note that neither Interest nor Data packets carry any host or 
> interface addresses (such as IP addresses); Interest packets are 
> routed towards data producers based on the names carried in the 
> Interest packets, and Data packets are returned based on the state 
> information set up by the Interests at each router hop."
>
> So it's basically suggesting a NAT-like table in every single router.
> And we all know how well NAT boxes scale...
>
  the pending interest table is more similar to multicast routing table,
which is maintained by end user subscriptions -- still challenging wrt
to scalability.


Cheers
  matthias

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:waehli...@ieee.org .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net

Per policy session cap on Juniper SRX

[Anurag Bhatia]

Hello everyone!


I have a Juniper SRX firewall and in recent times I did had issues because
one or other user doing an attack outside. Usually it is compromised client
machines which create a lot of firewall sessions in outside direction.


I was thinking of two specific things as fix for this:


   1. Can I somehow put a cap per security policy so that all available
   sessions aren't chewed by clients?

   2. We have very few clients who actually use firewall in outbound, rest
   all in inbound. This I wish to skip firewall in outbound but in my test I
   found it behaves strange. I tried with machine having inbound traffic via
   firewall. They ping and port 80 also worked but SSH just hung up as soon as
   I started. I see SRX can be used in unidirectional setup but somehow it
   fails in my case.



Any suggestions/advice/ sample configs?


Thanks in advance!

-- 


Anurag Bhatia
anuragbhatia.com

Linkedin  | Twitter

Skype: anuragbhatia.com

PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2

Re: no more "Send through Gmail" option

[Owen DeLong]

You would also need to not care about sending email to IPv6 domains.

Owen

On Sep 5, 2014, at 16:01 , ITechGeek  wrote:

> As a replacement, you can use Amazon SES and verify single email addresses
> if you don't have access over the whole domain.
> 
> ---
> -ITG (ITechGeek)
> i...@itechgeek.com
> https://itg.nu/
> GPG Keys: https://itg.nu/contact/gpg-key
> Preferred GPG Key: Fingerprint: AB46B7E363DA7E04ABFA57852AA9910A DCB1191A
> Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook:
> http://fb.me/Jbwa.Net
> 
> 
> On Fri, Sep 5, 2014 at 6:43 PM, Royce Williams 
> wrote:
> 
>> On Fri, Sep 5, 2014 at 2:15 PM, Eduardo A. Suárez
>>  wrote:
>>> 
>>> Hi,
>>> 
>>> according to this thread:
>>> 
>>> 
>> https://productforums.google.com/forum/#!category-topic/gmail/GyeMcHv1U-g%5B1-25-false%5D
>>> 
>>> Gmail isn't allowing anymore "Send through Gmail" option.
>> 
>> Yep. Existing email-address setups are grandfathered, but no new ones
>> can be added via the UI.
>> 
>> It's probably a mix of "let's support the ecosystem by only sending
>> mail from servers authorized by the domain holder" and "let's sell
>> more Google for Work email hosting".
>> 
>> If it really was more the former, there would be a "if your SPF
>> records include:_spf.google.com, you can still do it" option, IMO.
>> 
>> Royce
>> 

Re: The Next Big Thing: Named-Data Networking

[Rubens Kuhl]

>
> There would be a root, or multiple roots, which would respond to
> requests to locate who should be asked about a domain, for example if
> you want to know the ip address for world.std.com the conversation
> goes roughly:
>
>(To Root Server):   Where is the COM server?
>(From Root Server): SOMEHOST
>(TO SOMEHOST):  Where is the STD.COM server?
>(From SOMEHOST):192.137.74.112
>(TO 192.74.137.112):WHAT IS WORLD.STD.COM's IP ADDRESS (A RECORD)?
>(FROM 192.74.137.112):  192.74.137.5
>
> Not quite right. It actually goes like this on the wire:

(To Root Server):   WHAT IS WORLD.STD.COM 's
IP ADDRESS (A RECORD)?
   (From Root Server): I don't know, but SOMEHOST is the one to ask
about COM
   (TO SOMEHOST):   WHAT IS WORLD.STD.COM 's IP
ADDRESS (A RECORD)?
   (From SOMEHOST): I don't know, but 192.74.137.112 is the one to ask
about STD.COM
   (TO 192.74.137.112):WHAT IS WORLD.STD.COM 's
IP ADDRESS (A RECORD)?
   (FROM 192.74.137.112):  192.74.137.5

Or the DNSSEC option:

(To Root Server):   WHAT IS WORLD.STD.COM 's
IP ADDRESS (A RECORD)?
   (From Root Server): I don't know, but SOMEHOST is the one to ask
about COM, and you can trust SOMEONE if it signs with COM-Key. Signed with
ROOT-Key.
   (TO SOMEHOST):   WHAT IS WORLD.STD.COM 's IP
ADDRESS (A RECORD)?
   (From SOMEHOST): I don't know, but 192.74.137.112 is the one to ask
about STD.COM, and and you can't tell whether you are really talking to
192.74.137.112  since it's not signed. Signed with COM-Key.
   (TO 192.74.137.112):WHAT IS WORLD.STD.COM 's
IP ADDRESS (A RECORD)?
   (FROM 192.74.137.112):  192.74.137.5.


Rubens

Re: The Next Big Thing: Named-Data Networking

[Jared Mauch]

On Fri, Sep 05, 2014 at 07:40:08AM -0700, Paul Ferguson wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 9/5/2014 7:35 AM, Jay Ashworth wrote:
> 
> > "Interface" sure.
> > 
> > But the dangers of replacing actual /addresses/ with things which
> > are not is sufficiently well understood that even Van Jacobson
> > ought to know about 'em, right? :-)
> > 
> 
> Compare & contrast: There is still large-scale resistance (for lack of
> a better term) to IPv6 deployment, so what chance does deployment of
> Named Data-Networking stand? :-)

resistance [to ipv6] is futile - 
http://www.spreadshirt.com/-C3376A12786302

I certainly don't think IPv6 will reach 100% deployment, people
will continue [to get paid?] to operate 6to4 and 4to6 gateways, even if just
enterprise edge from a nat44(+) gateways.

I'm still waiting for a few orgs to make the IPv6 jump like
Wayport/attwifi as an example.  They could do nat66 like they do nat44
and easily make the sites look the same through their templates.

If you assume most people are right and Netflix is 33% of the US
internet at peak, that's 33% that's fully ipv6 capable on the server-side.
facebook, google and others count up as well, so much of content is reachable.

If apple/icloud make the jump to publishing  records as part
of their CDN efforts to move away from akamai, I suspect much more of the
LTE traffic would make that jump to v6.  (Waiting to see ATT upgrade their LTE
to support v6 to match VZ).

It also appears that OSX 10.10 fixes some of the IPv6 issues that exist
in 10.9, so with that update in the coming months I'm expecting even more IPv6
traffic to replace the IPv4 bits.

- Jared

-- 
Jared Mauch  | pgp key available via finger from ja...@puck.nether.net
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

Re: no more "Send through Gmail" option

[Rich Kulawiec]

On Fri, Sep 05, 2014 at 07:01:41PM -0400, ITechGeek wrote:
> As a replacement, you can use Amazon SES and verify single email addresses
> if you don't have access over the whole domain.

Not if you want people to accept your mail.  Thanks to Amazon's policy
of (a) allowing unlimited spam and (b) ignoring all abuse reports [1],
it's long since become a best practice to refuse all SMTP traffic from
amazonses.com, compute-1.amazonaws.com, compute.amazonaws.com and whatever
other subdomains they have/will have associated with that part of their
operation.

---rsk

[1] Which they don't make easy to file.  Instead of accepting reports at
abuse@, like every other responsible, professional, properly managed
operation, they force complainers to jump through hoops...in order
to file a complaint...which they studiously ignore.