[arin-ppml] ULA-C

[George Bonser]

To clarify, if you attempt to route RFC1918 across the internet, how do
you ensure it gets to the desired destination if thousands of potential
destinations are using that space and possibly hundreds of them are
announcing it (and being ignored) by their upstream.

Yes, it is "possible" to route rc1918 traffic across the internet but
there is no assurance that the rfc1918 network it is going to is your
desired "target".

It would require an incredible fluke of circumstances for that to
happen:

1. Source network announcing their RFC1918 space
2. Transit network accepting their RFC1918 space and nobody else's
except destination network.
3. Transit network announcing source network's RFC1918 space to
destination network.
4. Destination network accepting RFC1918 address space.
5. Destination network announcing RFC1918 address space and transit
provider accepting the announcement.
6. If multiple transit networks involved, they all accept both source
and destination RFC1918 space and no others becsuse that would "muddy
the water".
7. Not likely to happen on this planet but possible.



> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com]
> Sent: Sunday, April 11, 2010 10:18 PM
> To: joel jaeggli
> Cc: George Bonser; mcr at sandelman.ca; arin-ppml at arin.net
> Subject: Re: [arin-ppml] ULA-C
> 
> Well said.  Even RFC-1918 space can be routed across the global
> internet due to misconfiguration, so, I fail to see how that can
> possibly provide the protection described.
> 
> Admittedly, the number of misconfigurations increases in inverse
> proportion to topological proximity, but, nonetheless, lots of routing
> tables see RFC-1918 space on the global internet due to
> misconfiguration.
> 
> Why would ULA-C or any other "special" prefix be any different?
> 
> Owen
> 
> On Apr 11, 2010, at 7:14 PM, joel jaeggli wrote:
> 
> > Oddly, I work for mondo-megacorp and I find it interesting that
> you're speaking for all entities that fit that category collectively.
> >
> > From my vantage point ,the security posture associated with a
> particular prefix, service or network internal to our administrative
> domain is defined by requirements not by some intrinsic nature of the
> prefix.
> >
> > George Bonser <gbonser at seven.com> wrote:
> >
> >>
> >>
> >>> -----Original Message-----
> >>> From: joel jaeggli [mailto:joelja at bogus.com]
> >>> Sent: Sunday, April 11, 2010 6:37 PM
> >>> To: George Bonser; mcr at sandelman.ca
> >>> Cc: arin-ppml at arin.net
> >>> Subject: Re: [arin-ppml] ULA-C
> >>>
> >>> Mondo-megacorp will trivially have enough gua space to address
it's
> >>> extranet and the cost of aquiring space is negible compared to
cost
> of
> >>> deploying anything inside mondo-megacorp.
> >>>
> >>> Joel
> >>>
> >>
> >> Joel, you missed the point.  The do not want their financial
backend
> systems on globally routable address space.
> >>
> >> They do not want it to even be POSSIBLE that by some kind of
> misconfiguration, their systems could be reachable from the Internet.
> So they put it in address space that is impossible to be reached
across
> the public Internet.
> >>
> >>
> >>
> >>
> >>
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.