Re: ISP compliance < LEAs - tech and logistics [was: snfc21 sniffer docs]

[Martin Hannigan]

At 09:48 PM 5/23/2006, Sean Donelan wrote:


On Tue, 23 May 2006, Steven M. Bellovin wrote:
> > Indeed. To be honest, I am more interested in NANOG-related operational
> > issues involved, which I am not sure many here will be able to discuss in
> > case they had experience on the subject. So let us put privacy and legal
> > issues aside for the purpose of this discussion.
> >
> > How does a service provider handle the requirement to meet a law
> > enforcement agency with their wiretapping needs? The logistics and
> > technology can be exerting, annoying and business-wise, even prohibiting.
>
> In the US, see 18 USC 2518(4):
>
>   Any provider of wire or electronic communication service,
>   landlord, custodian or other person furnishing such facilities or
>   technical assistance shall be compensated therefor by the
>   applicant for reasonable expenses incurred in providing such
>   facilities or assistance.

The NANOG meeting archives are full of presentations as the result
of very sophisticated network monitoring.  Like most technology,
it can be used for good and evil.  You can't tell the motivation
just from the technology.



Sean, please drop this subject. You have no experience here and it's
annoying that you keep making authoritative claims like you have some
operational experience in this area. If you do, please do elaborate
and correct me. From what I understand from the folks at SBC, you
did not run harassing call, annoyance call, and LAES services. I would
appreciate a correction.

-M<








--
Martin Hannigan(c) 617-388-2663
Renesys Corporation(w) 617-395-8574
Member of Technical Staff  Network Operations
   [EMAIL PROTECTED]  

Re: AS12874 - FASTWEB

[Suresh Ramasubramanian]

On 5/22/06, Mikisa Richard <[EMAIL PROTECTED]> wrote:


Anyone from  FASTWEB please get back to me offline.



This page for fastweb (from an ISP in Africa) plus Ernest / Afrinic's
post asking people to update bogon filters for 41/8 .. both related.

Reason - fastweb provides NAT'ted ADSL lines to its users.  And its
users get IPs from 41/8 (among other /8s) - which was unallocated when
they originally started using it for their dsl pool instead of using
RFC1918 IPs like everybody else does.



Fastweb seems to think 41/8 is a dsl pool for its users in Turin

- 1/8  -> IP assegnati alla MAN di Milano
- 2/8  -> IP assegnati alla MAN di Milano Hinterland NORD
- 5/8  -> IP assegnati alla MAN di Genova
- 14/8 -> IP assegnati alla MAN di Milano Hinterland SUD
- 23/8 -> IP assegnati alla MAN di Roma
- 29/8 -> IP assegnati alla MAN del Triveneto
- 31/8 -> IP assegnati alla MAN di Bari
- 37/8 -> IP assegnati alla MAN di Bologna
- 39/8 -> IP assegnati alla MAN di Napoli
- 41/8 -> IP assegnati alla MAN di Torino
- 42/8 -> IP assegnati alla MAN di Reggio Emilia

--
Suresh Ramasubramanian ([EMAIL PROTECTED])

Re: ISP compliance < LEAs - tech and logistics [was: snfc21 sniffer docs]

[Sean Donelan]

On Tue, 23 May 2006, Steven M. Bellovin wrote:
> > Indeed. To be honest, I am more interested in NANOG-related operational
> > issues involved, which I am not sure many here will be able to discuss in
> > case they had experience on the subject. So let us put privacy and legal
> > issues aside for the purpose of this discussion.
> >
> > How does a service provider handle the requirement to meet a law
> > enforcement agency with their wiretapping needs? The logistics and
> > technology can be exerting, annoying and business-wise, even prohibiting.
>
> In the US, see 18 USC 2518(4):
>
>   Any provider of wire or electronic communication service,
>   landlord, custodian or other person furnishing such facilities or
>   technical assistance shall be compensated therefor by the
>   applicant for reasonable expenses incurred in providing such
>   facilities or assistance.

The NANOG meeting archives are full of presentations as the result
of very sophisticated network monitoring.  Like most technology,
it can be used for good and evil.  You can't tell the motivation
just from the technology.

Re: ISP compliance < LEAs - tech and logistics [was: snfc21 sniffer docs]

[Steven M. Bellovin]

On Tue, 23 May 2006 05:39:26 -0500 (CDT), Gadi Evron <[EMAIL PROTECTED]>
wrote:

> 
> > Wired posted what are suppossedly the docs Mark Klein wrote 'bout the
> > NSA sniffing project.  Interesting read...
> > 
> > http://blog.wired.com/27BStroke6/att_klein_wired.pdf
> > 
> > John
> 
> Indeed. To be honest, I am more interested in NANOG-related operational
> issues involved, which I am not sure many here will be able to discuss in
> case they had experience on the subject. So let us put privacy and legal
> issues aside for the purpose of this discussion.
> 
> How does a service provider handle the requirement to meet a law
> enforcement agency with their wiretapping needs? The logistics and
> technology can be exerting, annoying and business-wise, even prohibiting.
> 
In the US, see 18 USC 2518(4):

Any provider of wire or electronic communication service,
landlord, custodian or other person furnishing such facilities or
technical assistance shall be compensated therefor by the
applicant for reasonable expenses incurred in providing such
facilities or assistance.



--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

MAE-WEST - 55 S Market area equipment sourcing

[Rodney Joffe]

Sorry for the noise, but this is sorta operational (for me anyway ;-))

We are physically in the process of configuring the connectivity for  
NANOG 37. "We" are from "out of town" ;-)


It has not been easy (when has it ever been?).

Accept the following: We have to transit some existing infrastructure  
that is restricted to 100Mb FE over Copper with RJ45 connectors.


On one side, we have to connect the FE connection to a Gbic equipped  
router over existing single mode, with either an SC or FC connector  
(the patch panel accepts either of these).


On the other side of the link we have to connect the FE connection to  
a Gbic equipped router over existing multimode mode, with an ST  
connector (the patch panel accepts only this)


Can anyone point me to a source in the 55 S Market area that might  
have the appropriate intelligent media conversion devices actually in  
stock, at a reasonable price, and not "1-2 days" out? Bearing in mind  
that besides converting media, I have to convert speed for the Gbics?  
And I am trying to avoid the cost of getting two switches, and  
installing appropriate Gbics in them :-/


Thanks
/rlj

Re: ISP compliance < LEAs - tech and logistics [was: snfc21 sniffer docs]

[James J. Lippard]

On Tue, May 23, 2006 at 05:39:26AM -0500, Gadi Evron wrote:
> 
> > Wired posted what are suppossedly the docs Mark Klein wrote 'bout the
> > NSA sniffing project.  Interesting read...
> > 
> > http://blog.wired.com/27BStroke6/att_klein_wired.pdf
> > 
> > John
> 
> Indeed. To be honest, I am more interested in NANOG-related operational
> issues involved, which I am not sure many here will be able to discuss in
> case they had experience on the subject. So let us put privacy and legal
> issues aside for the purpose of this discussion.
> 
> How does a service provider handle the requirement to meet a law
> enforcement agency with their wiretapping needs? The logistics and
> technology can be exerting, annoying and business-wise, even prohibiting.

See RFC 3924, "Cisco Architecture for Lawful Intercept in IP Networks."
 
-- 
Jim Lippard [EMAIL PROTECTED]
Global Security Organization, Information Security Architecture
Global Crossing
GPG Key ID: 0xED3D63C0

Re: [Way OT] Re: Geo location to IP mapping

[Roland Perry]

In article <[EMAIL PROTECTED]>, Jeroen 
Massar <[EMAIL PROTECTED]> writes

Try http://www.hostip.info it is reasonable accurate in most cases and
hell it is for free. It depends what you need it for of course but it is
far better than nothing.

The problem with this one is that they are still gathering data and they
depend on user input, but it looks pretty accurate to what I have found
out.


The problem with their "user input" is that the result they return is 
typically the ISP NOC location (in my case 200 miles south of me, about 
halfway across the country).


If I "correct" this, then suddenly all my ISP's users appear to be 
located in the same town as me. Which is probably more wrong than them 
all appearing to be where they've guessed the NOC location to be.

--
Roland Perry

Re: private ip addresses from ISP

[Joseph S D Yao]

On Tue, May 23, 2006 at 11:55:56AM -0400, Joe Maimon wrote:
...
> Its also quite annoying to wait for each hop to timeout.


Well, yes.  ;-}  But as someone hinted, that's purely a problem with my
own psyche, which I do [to some degree] control.

OBTW, the 'ad hominem' attacks starting up in this thread should really
be deprecated [speaking of which].


-- 
Joe Yao
---
   This message is not an official statement of OSIS Center policies.

Re: private ip addresses from ISP

[Patrick W. Gilmore]

On May 23, 2006, at 1:14 PM, Richard A Steenbergen wrote:

[...]

Filtering every last 1918 sourced packet you receive because it  
might have

a DoS is like filtering all ICMP because people can ping flood. If you
want to rate limit it, that is reasonable. If you want to restrict  
it to
ICMP responses only, that is also reasonable. If on the other hand  
you are

determined to filter every 1918 sourced packets between AS boundries
(including ttl exceed, mtu exceed, and dest unreachable) because an  
RFC
told you you "should", you are actually doing your customers a  
disservice.


If you are an end-user network or don't transit other people's  
packets and
you want to do yourself a disservice then by all means filter 1918  
sourced
packets until you are blue in the face. If on the other hand you do  
handle

other people's packets, I would encourage you to fully consider the
ramifications before you go out and apply those filters. This is  
why k00ks
who can only cite RFC's instead of think for themselves and large  
networks

tend to be a bad mix. :)


No one is arguing that you should ruin your business because an RFC  
told you to.  (At least no one reasonable.)  However, in your first  
post you said:



If you're receiving RFC1918 sourced packets, for the
most part you really shouldn't care. There are semi-legitimate  
reasons for

packets with those sources addresses to float around the Internet, and
they don't hurt anything.


I disagree.  As do many people.  You -should- care when people do bad  
things.  And passing bogon-source packets between ASes is a Bad Thing.


You suggest thwacking people "over the head with a cluebat" when they  
send you 1918 prefixes.  Is that really a problem?  It's easy to  
filter (as everyone should be doing already), and doesn't really  
'break' anything.  So why the vehemence?  Because it is a Bad Thing.   
And the Internet doesn't work if everyone does Bad Things.  As a  
result, you get upset when people do Bad Things.


But, as you point out, sometimes customers are stupid.  So sometimes  
you have to do things that upset you.  You get paid for connectivity,  
and customers don't understand why certain actions hurt the Internet.


For instance, I get pissed when someone sends 256 /24s instead of  
one /16.  But that doesn't mean I suggest filtering all 256 /24s.   
Customers would get pissed if they can't reach their fav pr0n server  
in that /16.  Similarly, if someone sends you 1918-sourced packets,  
you may have to accept them to keep your customers happy.  But you  
should care.  And you should be upset.


Telling people they need to see a shrink for trying to keep the 'Net  
clean is not the correct response.


--
TTFN,
patrick

Re: private ip addresses from ISP

[sthaug]

> Filtering every last 1918 sourced packet you receive because it might have 
> a DoS is like filtering all ICMP because people can ping flood. If you 
> want to rate limit it, that is reasonable. If you want to restrict it to 
> ICMP responses only, that is also reasonable. If on the other hand you are 
> determined to filter every 1918 sourced packets between AS boundries 
> (including ttl exceed, mtu exceed, and dest unreachable) because an RFC 
> told you you "should", you are actually doing your customers a disservice.

Well, some of us happen to disagree. I have been very happy to see that
both at my previous and at my present employer (large SPs by Norwegian
standards), all 1918 traffic is filtered at the borders. We have never
had any trouble from customers because of this, and we certainly intend
to keep the filters. And yes, we have had these filters in place for
several years...

Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]

Re: private ip addresses from ISP

[Richard A Steenbergen]

On Tue, May 23, 2006 at 12:23:54PM -0400, Patrick W. Gilmore wrote:
> 
> I know it was late when you wrote that, RAS, but from the  
> _very_first_sentence_:

Er yeah I meant to say it says nothing about filtering 1918 packets. 

> Please read BCP38 again.  (For the first time? :)

Clearly allowing anyone to inject large quantities of spoofed packets into 
the Internet is Bad (tm), no one is arguing that. First of all note that I 
was talking about how you deal with packets you receive, not packets you 
send. Hate to bust out the old "be conservative in what you send and 
liberal in what you receive" line, but in this case it is true. There are 
legitimate uses for RFC1918 sourced packets (as has been pointed out many 
times, for example, ICMP responses from people who want/need their routers 
to not source packets from publicly routed space).

Filtering every last 1918 sourced packet you receive because it might have 
a DoS is like filtering all ICMP because people can ping flood. If you 
want to rate limit it, that is reasonable. If you want to restrict it to 
ICMP responses only, that is also reasonable. If on the other hand you are 
determined to filter every 1918 sourced packets between AS boundries 
(including ttl exceed, mtu exceed, and dest unreachable) because an RFC 
told you you "should", you are actually doing your customers a disservice.

If you are an end-user network or don't transit other people's packets and 
you want to do yourself a disservice then by all means filter 1918 sourced 
packets until you are blue in the face. If on the other hand you do handle 
other people's packets, I would encourage you to fully consider the 
ramifications before you go out and apply those filters. This is why k00ks 
who can only cite RFC's instead of think for themselves and large networks 
tend to be a bad mix. :)

-- 
Richard A Steenbergen <[EMAIL PROTECTED]>   http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

Re: private ip addresses from ISP

[Patrick W. Gilmore]

On May 23, 2006, at 10:47 AM, Robert Bonomi wrote:


Really? You really want TTL-E messages with RFC1918 source addr? Even
if they're used as part of a denial of service attack? Even though
you can't tell where they actually came from?


"Can be" is not sufficient (in and of itself, that is) reason to  
block.

_Anything_ "can be" used as part of a DOS attack.

TTL-E messages _do_ have legitimate function in network management.
TTL-E messages _can_ originate from RFC1918 space,  addressed to  
'public
internet' addresses.  Usefully, and meaningfully.  Ever hear of  
'traceroute'?
Ever use it where packets went across a network using RFC1918  
internally?
Ever had a route die _between_ two RFC1918 addressed nodes on  
somebody elses

network?

If you don't like that example, substitute "host/network  
unreachable", or
'ICMP redirect'. Or packet-size limit exceeded for a 'DNF' packet.   
If you

don't get those messages back, you can't communicate.


Robert, to quote your own words: "You're either ignorant of network  
architecture, or trying to pick fights."


TTL-E messages "can" originate from any IP address.  They should  
not.  And allowing packets with RFC1918 source addresses to leave  
your administrative domain is bad network administration (not to  
mention going against the RFC).  There are no loopholes here, you are  
being a bad 'Netizen if you pass packets with bogon source addresses  
to your peers.  Period.


If you have issues where you need to send DNF or other messages to  
peers, it is incumbent upon _you_ to ensure those messages originate  
with valid source addresses.


It is perfectly acceptable - even good network hygiene - for other  
networks to drop any packets with bad source addresses at their  
boarder.  You cannot expect them to accept your packets just because  
you don't know how to architect a network properly.  If that breaks  
traceroute or PMTU-D or anything else, that is your fault, not theirs.


Please read RFC1918 again, as well as BCP38.  And perhaps a book on  
networking.


--
TTFN,
patrick

Re: private ip addresses from ISP

[Patrick W. Gilmore]

On May 23, 2006, at 3:33 AM, Richard A Steenbergen wrote:


From RFC 1918
   Because private addresses have no global meaning, routing  
information

   about private networks shall not be propagated on inter-enterprise
   links, and packets with private source or destination addresses
   should not be forwarded across such links. Routers in networks not
   using private address space, especially those of Internet service
   providers, are expected to be configured to reject (filter out)
   routing information about private networks.

The ISP shouldn't be "leaving" anything to the end-user, these  
packets

should be dropped as a matter of course, along with any routing
advertisements for RFC 1918 space(From #1). ISP's who leak 1918 space
into my network piss me off, and get irate phone calls for their
trouble.


The section you quoted from RFC1918 specifically addresses routes, not
packets.


I know it was late when you wrote that, RAS, but from the  
_very_first_sentence_:



and packets with private source or destination addresses
   should not be forwarded across such links




If you're receiving RFC1918 *routes* from anyone, you need to
thwack them over the head with a cluebat a couple of times until  
the cluey
filling oozes out. If you're receiving RFC1918 sourced packets, for  
the
most part you really shouldn't care. There are semi-legitimate  
reasons for

packets with those sources addresses to float around the Internet, and
they don't hurt anything. If you really can't stand seeing an RFC1918
sourced packet over the Internet it is more of a personality  
problem than
a networking problem, so a good shrink is probably going to be more  
useful

than a good firewall.


Incorrect.  Not to mention Just Plain Wrong.

Please read BCP38 again.  (For the first time? :)

--
TTFN,
patrick

Re: private ip addresses from ISP

[Joe Maimon]

Joseph S D Yao wrote:


Folks are sounding as if they'd never 'traceroute'd THROUGH a set of
unroutable IP addresses.  I have seen cases where my 'traceroute' looked
like this [when I've had the patience to not hit Interrupt at the first
sign of stars]:

 1  1 ms  1 ms  1 ms  router.here
 2 10 ms 10 ms 10 ms  router.there
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7 80 ms 80 ms 80 ms  router.over.yonder
 8 90 ms 90 ms 90 ms  host.over.yonder

It works!



Its also quite annoying to wait for each hop to timeout.

Re: private ip addresses from ISP

[Joseph S D Yao]

On Tue, May 23, 2006 at 04:22:26PM +0100, [EMAIL PROTECTED] wrote:
...
> Does NANOG have a role in developing some best
> practices text that could be easily imcorporated
> into peering agreements and service contracts?
...


RFC 2267 -> RFC 2827 == Best Current Practice (BCP) 38

RFC 3013 == BCP 46

RFC 3704 == BCP 84

Are these followed?


-- 
Joe Yao
---
   This message is not an official statement of OSIS Center policies.

Re: private ip addresses from ISP

[Joseph S D Yao]

Folks are sounding as if they'd never 'traceroute'd THROUGH a set of
unroutable IP addresses.  I have seen cases where my 'traceroute' looked
like this [when I've had the patience to not hit Interrupt at the first
sign of stars]:

 1  1 ms  1 ms  1 ms  router.here
 2 10 ms 10 ms 10 ms  router.there
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7 80 ms 80 ms 80 ms  router.over.yonder
 8 90 ms 90 ms 90 ms  host.over.yonder

It works!


-- 
Joe Yao
---
   This message is not an official statement of OSIS Center policies.

Re: private ip addresses from ISP

[Joe Maimon]

Robert Bonomi wrote:


Date: Tue, 23 May 2006 11:14:53 -0400




"Translating" those addresses is a *BAD*IDEA*(TM).  That obscures who
the reporting machine was _if_ you have to actually communicate with that
network operator.



These are the options:

Construct the network so that icmp is never sourced from rfc1918

OR

Do either of below:

Filter icmp sourced from rfc1918 on egress

Dont filter icmp sourced from rfc1918 on egress

Translate icmp sourced from rfc1918 on egress

Use some feature that translates/replaces rfc1918 sourced icmp with 
nonrfc1918 identifiable internally.



This is exactly why RFC1918 says that private-addrss source packets _should_
_not_ be passed across enterprise boundaries.  It does _not_ say 'must not',
because there *are* situations where it is necessary. This _is_ one of them. :)


You are in favor of:

Dont filter icmp sourced from rfc1918 on egress

However that leads to a significant hole in "anti spoofing defense 
sheild" of the net.


So it becomes difficult to be in favor of this and also claim that 
liberal application of anti-spoofing/urpf will solve most of the abuses 
which depend on spoofing to be effective.






Understandably, translation on providers networks is not always feasible.

A feature on routers that sourced icmp packets to be told specificaly 
which address of the router to source it from would also help.



When the router has only RFC1918 addresses (totally internal to the network),
it doesn't matter/help.


In this instance they would assign a single or more address nonrfc1918 
to leverage this feature.




Also, the address to use as the source _is_ well-defined.  it is the interface
the packet came in on that triggered the ICMP message.


The proposed feature would make it configurable, perhaps on a per 
interface basis.


The provider would keep an internal database. It need not even be routed.

It would be nice if this was completely an icmp packet field value and 
not dependant on the ip header to identify the icmp generator.

Re: private ip addresses from ISP

[Joe Maimon]

Brian Johnson wrote:



In the Cisco world, I thought that the source would always be the interface
that replies to the ICMP packet. That seems to be good form to me.

Where am I going wrong?



You are correct, however it could be usefull in regards to the topic at 
hand if this was configurable.

RE: private ip addresses from ISP

[Brian Johnson]

 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Joe Maimon
> Sent: Tuesday, May 23, 2006 10:15 AM
> To: Robert Bonomi
> Cc: [EMAIL PROTECTED]
> Subject: Re: private ip addresses from ISP
> 
> 
> 
> 
> Robert Bonomi wrote:
> 
> > 
> > TTL-E messages _do_ have legitimate function in network management.
> > TTL-E messages _can_ originate from RFC1918 space,  
> addressed to 'public
> > internet' addresses.  Usefully, and meaningfully.  Ever 
> hear of 'traceroute'?
> > Ever use it where packets went across a network using 
> RFC1918 internally?
> > Ever had a route die _between_ two RFC1918 addressed nodes 
> on somebody elses
> > network?
> 
> I guess this means that providers who utilize rfc1918 along 
> their hops 
> should make an effort to ensure these addresses are not used for icmp 
> messages or translate these addresses when they source icmp.
> 
> Understandably, translation on providers networks is not 
> always feasible.
> 
> A feature on routers that sourced icmp packets to be told specificaly 
> which address of the router to source it from would also help.

In the Cisco world, I thought that the source would always be the interface
that replies to the ICMP packet. That seems to be good form to me.

Where am I going wrong?

> 
> 

Re: private ip addresses from ISP

[Michael . Dillon]

> Proper "good net neighbor" egress filtering of RFC1918 source addresses 
> takes a number of separate rules.  Several 'allows', followed by a 
default
> 'deny'.

Really?
Do you have those rules on your network?
Any reason why you didn't post the operational
details on this operational list?

Have you ever read your peering agreements or
service contracts to see if filtering of RFC 1918
sourced traffic is specifically covered by them?
If it is not covered by the contract, then why should
your peers/upstreams filter it?

Another good question is whether or not every
service contract and peering agreement should
contain unique text or whether there should be
some community-developed best practices statement
that could be plugged in by reference. For instance,
software publishers can publish their software
under the terms of the GPL without including the
full text of the GPL verbatim in their software
license.

Does NANOG have a role in developing some best
practices text that could be easily imcorporated
into peering agreements and service contracts?

--Michael Dillon

Re: private ip addresses from ISP

[Joe Maimon]

Robert Bonomi wrote:



TTL-E messages _do_ have legitimate function in network management.
TTL-E messages _can_ originate from RFC1918 space,  addressed to 'public
internet' addresses.  Usefully, and meaningfully.  Ever hear of 'traceroute'?
Ever use it where packets went across a network using RFC1918 internally?
Ever had a route die _between_ two RFC1918 addressed nodes on somebody elses
network?


I guess this means that providers who utilize rfc1918 along their hops 
should make an effort to ensure these addresses are not used for icmp 
messages or translate these addresses when they source icmp.


Understandably, translation on providers networks is not always feasible.

A feature on routers that sourced icmp packets to be told specificaly 
which address of the router to source it from would also help.

Re: private ip addresses from ISP

[Robert Bonomi]

> Date: Tue, 23 May 2006 09:36:30 -0400
> To: [EMAIL PROTECTED]
> From: Daniel Senie <[EMAIL PROTECTED]>
> Subject: Re: private ip addresses from ISP
>
>
> At 09:22 AM 5/23/2006, Robert Bonomi wrote:
>
> > > Date: Tue, 23 May 2006 03:33:34 -0400
> > > From: Richard A Steenbergen <[EMAIL PROTECTED]>
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: private ip addresses from ISP
> > >
> > >
> > > On Mon, May 22, 2006 at 04:30:37PM -0400, Andrew Kirch wrote:
> > > >
> > > > >   3) You are seeing packets with source IPs inside private space
> > > > > arriving at
> > > > > your interface from your ISP?
> > > ...
> > > > Sorry to dig this up from last week but I have to strongly disagree with
> > > > point #3.
> > > > >From RFC 1918
> > > >Because private addresses have no global meaning, routing information
> > > >about private networks shall not be propagated on inter-enterprise
> > > >links, and packets with private source or destination addresses
> > > >should not be forwarded across such links. Routers in networks not
> > > >using private address space, especially those of Internet service
> > > >providers, are expected to be configured to reject (filter out)
> > > >routing information about private networks.
> > > >
> > > > The ISP shouldn't be "leaving" anything to the end-user, these packets
> > > > should be dropped as a matter of course, along with any routing
> > > > advertisements for RFC 1918 space(From #1). ISP's who leak 1918 space
> > > > into my network piss me off, and get irate phone calls for their
> > > > trouble.
> > >
> > > The section you quoted from RFC1918 specifically addresses routes, not
> > > packets.
> >
> >I quote, from the material cited above:
> >   "  ..., and packets with private source or destination addresses
> >should not be forwarded across such links.  ...  "
> >
> >There are some  types of packets that can legitimately have RFC1918 source
> >addresses --  'TTL exceeded' for example -- that one should legitimately
> >allow across network boundaries.
>
> Really? You really want TTL-E messages with RFC1918 source addr? Even 
> if they're used as part of a denial of service attack? Even though 
> you can't tell where they actually came from?

"Can be" is not sufficient (in and of itself, that is) reason to block. 
_Anything_ "can be" used as part of a DOS attack.

TTL-E messages _do_ have legitimate function in network management.
TTL-E messages _can_ originate from RFC1918 space,  addressed to 'public
internet' addresses.  Usefully, and meaningfully.  Ever hear of 'traceroute'?
Ever use it where packets went across a network using RFC1918 internally?
Ever had a route die _between_ two RFC1918 addressed nodes on somebody elses
network?

If you don't like that example, substitute "host/network unreachable", or
'ICMP redirect'. Or packet-size limit exceeded for a 'DNF' packet.  If you
don't get those messages back, you can't communicate.

> > >  If you're receiving RFC1918 *routes* from anyone, you need to
> > > thwack them over the head with a cluebat a couple of times until the cluey
> > > filling oozes out. If you're receiving RFC1918 sourced packets, for the
> > > most part you really shouldn't care.
> >
> >*I* care.
> >
> >When those packets contain 'malicious' content, for example.
> >
> >When the provider =cannot= tell me which of _their_own_customers_ originated
> >that attack, for example.  (This provider has inbound source-filtering on
> >their Internet 'gateway' routers, but *not* on their customer-facing 
> >equipment
> >(either inbound or outbound.)
>
> So you really don't want ANY packets with RFC 1918 source addresses 
> then, not even ICMP TTL-E messages, since they could be used in a 
> malicious fashion, and you would not be able to determine the true origin.

You need to learn to read.  I said "malicious content", not 'used in a
malicious fashion'.

Packets that could have legitimate meaning should be passed on.

Packets that _cannot_ have legitimate meaning should not be.

> >It's even more comical when the NSP uses RFC1918 space internally, and does
> >*not* filter those source addresses from their customers.
>
> You mean like Comcast using Cisco routers in their head-ends and 
> having the 10/8 address show up in traceroutes and so forth? 

not at all.  You're either ignorant of network architecture, or trying
to pick fights.

I was talking about a situation where a customer machine of a network
that uses RFC1918 addresses internally starts sending malicious packets
with a RFC1918 source address that _matches_ that of one of the *in*use*
addresses on the service-provider network.  AND the service-provider does
not do ingress (from the customer) or egress (to the customer) filtering
of RFC1918 address-space.  Customer A's machine starts attacking Customer 
B, C, D, E, F ...;  those ill-informed customers don't null-route outbound 
RFC1918 addresses; you get an 'inadvertent' smurf attack on the NSP resource.
It

RE: private ip addresses from ISP

[Frank Bulk]

While we're on the topic, perhaps I should ask for some best practices
(where 'best' equals one for every listserv member) on the use of RFC 1918
addresses within a network provider's infrastructure.

We use private addresses for some stub routes, as well as our cable modems.
Should we aggressively move away from private stub networks?  And for the
second, should we specifically limit access to those cable modem IPs to just
our management network ?  Right now any of customers could do an SNMP sweep
and identify them all, but I don't really care that much about that, or
should I?

And yes, I do have RFC 1918 filters on our outbound traffic. =)

Frank

Re: private ip addresses from ISP

[Daniel Senie]

At 09:22 AM 5/23/2006, Robert Bonomi wrote:


> Date: Tue, 23 May 2006 03:33:34 -0400
> From: Richard A Steenbergen <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: private ip addresses from ISP
>
>
> On Mon, May 22, 2006 at 04:30:37PM -0400, Andrew Kirch wrote:
> >
> > >   3) You are seeing packets with source IPs inside private space
> > > arriving at
> > > your interface from your ISP?
> ...
> > Sorry to dig this up from last week but I have to strongly disagree with
> > point #3.
> > >From RFC 1918
> >Because private addresses have no global meaning, routing information
> >about private networks shall not be propagated on inter-enterprise
> >links, and packets with private source or destination addresses
> >should not be forwarded across such links. Routers in networks not
> >using private address space, especially those of Internet service
> >providers, are expected to be configured to reject (filter out)
> >routing information about private networks.
> >
> > The ISP shouldn't be "leaving" anything to the end-user, these packets
> > should be dropped as a matter of course, along with any routing
> > advertisements for RFC 1918 space(From #1). ISP's who leak 1918 space
> > into my network piss me off, and get irate phone calls for their
> > trouble.
>
> The section you quoted from RFC1918 specifically addresses routes, not
> packets.

I quote, from the material cited above:
  "  ..., and packets with private source or destination addresses
   should not be forwarded across such links.  ...  "

There are some  types of packets that can legitimately have RFC1918 source
addresses --  'TTL exceeded' for example -- that one should legitimately
allow across network boundaries.


Really? You really want TTL-E messages with RFC1918 source addr? Even 
if they're used as part of a denial of service attack? Even though 
you can't tell where they actually came from?



>  If you're receiving RFC1918 *routes* from anyone, you need to
> thwack them over the head with a cluebat a couple of times until the cluey
> filling oozes out. If you're receiving RFC1918 sourced packets, for the
> most part you really shouldn't care.

*I* care.

When those packets contain 'malicious' content, for example.

When the provider =cannot= tell me which of _their_own_customers_ originated
that attack, for example.  (This provider has inbound source-filtering on
their Internet 'gateway' routers, but *not* on their customer-facing 
equipment

(either inbound or outbound.)


So you really don't want ANY packets with RFC 1918 source addresses 
then, not even ICMP TTL-E messages, since they could be used in a 
malicious fashion, and you would not be able to determine the true origin.




It's even more comical when the NSP uses RFC1918 space internally, and does
*not* filter those source addresses from their customers.


You mean like Comcast using Cisco routers in their head-ends and 
having the 10/8 address show up in traceroutes and so forth? Not sure 
to what degree it's the NSP's fault vs. the router vendors', but yes.




>  There are semi-legitimate reasons for
> packets with those sources addresses to float around the Internet, and
> they don't hurt anything.

I guess you don't mind paying for transit of packets that _cannot_possibly_
have any legitimate purpose on your network.


Along with this goes the usual flamewar over RFC 2827, ingress 
filtering (of which URPF is a subset implementation).




Some of us, on the other hand, _do_ object.


And some of us pay for bandwidth, care about getting congestion 
problems from useless traffic, etc. Perhaps it makes the case a lot 
clearer for selling "better than equal" service to the highest bidder 
if your network is overrun with undesired traffic.

RE: private ip addresses from ISP

[Andrew Kirch]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of
> Robert Bonomi
> Sent: Tuesday, May 23, 2006 9:22 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: private ip addresses from ISP
> 
> 
> > Date: Tue, 23 May 2006 03:33:34 -0400
> > From: Richard A Steenbergen <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: Re: private ip addresses from ISP
> >
> >
> > On Mon, May 22, 2006 at 04:30:37PM -0400, Andrew Kirch wrote:
> > >
> > > > 3) You are seeing packets with source IPs inside private
space
> > > > arriving at
> > > > your interface from your ISP?
> > ...
> > > Sorry to dig this up from last week but I have to strongly
disagree
> with
> > > point #3.
> > > >From RFC 1918
> > >Because private addresses have no global meaning, routing
> information
> > >about private networks shall not be propagated on
inter-enterprise
> > >links, and packets with private source or destination addresses
> > >should not be forwarded across such links. Routers in networks
not
> > >using private address space, especially those of Internet
service
> > >providers, are expected to be configured to reject (filter out)
> > >routing information about private networks.
> > >
> > > The ISP shouldn't be "leaving" anything to the end-user, these
packets
> > > should be dropped as a matter of course, along with any routing
> > > advertisements for RFC 1918 space(From #1). ISP's who leak 1918
space
> > > into my network piss me off, and get irate phone calls for their
> > > trouble.
> >
> > The section you quoted from RFC1918 specifically addresses routes,
not
> > packets.
> 
> I quote, from the material cited above:
>   "  ..., and packets with private source or destination addresses
>should not be forwarded across such links.  ...  "
> 
> There are some  types of packets that can legitimately have RFC1918
source
> addresses --  'TTL exceeded' for example -- that one should
legitimately
> allow across network boundaries.
> >  If you're receiving RFC1918 *routes* from anyone, you need
to
> > thwack them over the head with a cluebat a couple of times until the
> cluey
> > filling oozes out. If you're receiving RFC1918 sourced packets, for
the
> > most part you really shouldn't care.
> 
> *I* care.
> 
> When those packets contain 'malicious' content, for example.
> 
> When the provider =cannot= tell me which of _their_own_customers_
> originated
> that attack, for example.  (This provider has inbound source-filtering
on
> their Internet 'gateway' routers, but *not* on their customer-facing
> equipment
> (either inbound or outbound.)
> 
> It's even more comical when the NSP uses RFC1918 space internally, and
> does
> *not* filter those source addresses from their customers.
> 
> >  There are semi-legitimate
reasons
> for
> > packets with those sources addresses to float around the Internet,
and
> > they don't hurt anything.
> 
> I guess you don't mind paying for transit of packets that
> _cannot_possibly_
> have any legitimate purpose on your network.
> 
> Some of us, on the other hand, _do_ object.
> 
> YMMV
> 
Well said, I think that Robert has done a phenomenal job of summing up
my point.  I don't want this trash on my network.  The pertinent RFC
says it shouldn't be entering my network from *your* network (for
varying values of your).  I don't buy the argue that the end user should
decide what traffic they do and don't want when the RFC states
unequivocally that the traffic shouldn't be there. Even reasonably large
networks are often run by people with no appreciable networking
experience, MCSE, MCP MCP+I etc.  This is a simple fact of life.
 
Andrew

Re: private ip addresses from ISP

[Robert Bonomi]

> Date: Tue, 23 May 2006 03:33:34 -0400
> From: Richard A Steenbergen <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: private ip addresses from ISP
>
>
> On Mon, May 22, 2006 at 04:30:37PM -0400, Andrew Kirch wrote:
> > 
> > >   3) You are seeing packets with source IPs inside private space
> > > arriving at
> > > your interface from your ISP?
> ...
> > Sorry to dig this up from last week but I have to strongly disagree with
> > point #3.  
> > >From RFC 1918
> >Because private addresses have no global meaning, routing information
> >about private networks shall not be propagated on inter-enterprise
> >links, and packets with private source or destination addresses
> >should not be forwarded across such links. Routers in networks not
> >using private address space, especially those of Internet service
> >providers, are expected to be configured to reject (filter out)
> >routing information about private networks.
> > 
> > The ISP shouldn't be "leaving" anything to the end-user, these packets
> > should be dropped as a matter of course, along with any routing
> > advertisements for RFC 1918 space(From #1). ISP's who leak 1918 space
> > into my network piss me off, and get irate phone calls for their
> > trouble.
>
> The section you quoted from RFC1918 specifically addresses routes, not 
> packets.

I quote, from the material cited above:
  "  ..., and packets with private source or destination addresses
   should not be forwarded across such links.  ...  "

There are some  types of packets that can legitimately have RFC1918 source
addresses --  'TTL exceeded' for example -- that one should legitimately
allow across network boundaries.
>  If you're receiving RFC1918 *routes* from anyone, you need to 
> thwack them over the head with a cluebat a couple of times until the cluey 
> filling oozes out. If you're receiving RFC1918 sourced packets, for the 
> most part you really shouldn't care.

*I* care.  

When those packets contain 'malicious' content, for example.

When the provider =cannot= tell me which of _their_own_customers_ originated 
that attack, for example.  (This provider has inbound source-filtering on 
their Internet 'gateway' routers, but *not* on their customer-facing equipment 
(either inbound or outbound.)

It's even more comical when the NSP uses RFC1918 space internally, and does 
*not* filter those source addresses from their customers.

>  There are semi-legitimate reasons for 
> packets with those sources addresses to float around the Internet, and 
> they don't hurt anything. 

I guess you don't mind paying for transit of packets that _cannot_possibly_
have any legitimate purpose on your network.

Some of us, on the other hand, _do_ object. 

YMMV

ISP compliance < LEAs - tech and logistics [was: snfc21 sniffer docs]

[Gadi Evron]

> Wired posted what are suppossedly the docs Mark Klein wrote 'bout the
> NSA sniffing project.  Interesting read...
> 
> http://blog.wired.com/27BStroke6/att_klein_wired.pdf
> 
> John

Indeed. To be honest, I am more interested in NANOG-related operational
issues involved, which I am not sure many here will be able to discuss in
case they had experience on the subject. So let us put privacy and legal
issues aside for the purpose of this discussion.

How does a service provider handle the requirement to meet a law
enforcement agency with their wiretapping needs? The logistics and
technology can be exerting, annoying and business-wise, even prohibiting.

As I just mentioned somewhere else, I should probably point out that if I
was a major ISP often asked to answer the call of law enforcement with
legal wiretaps, this could be very annoying as well as technologically
a killer to my network architecture.
Just sticking some hub somewhere in my network may not cut it, and will
certainly not cover all of the communication. What about different lines
and locations?

As a large provider, AT&T probably had to find better solutions to the
call of the law, or reply on the law's technology to not kill their
business.

This indeed happened before. As some of you may remember, according to one
NANOGer at the FBI's Carnivore presentation a few years ago, "sticking"
just such a hub is what caused his network to break-down.

Creating a centralized wiretapping point under strict security may be just
the thing to both comply and save costs, not to mention staying on the
air.

I don't see how that _by_itself_ is wrong of AT&T. There are other issues
here as well.

The Internet Infrastructure in a significant way sits in the US. We all
know that. Is it really a surprise to anyone that the NSA, which states it
listens to the Internet, is using a local resource such as that on US
soil? They would be crazy not to.

They rivals and enemies in other countries certainly won't think
twice.

There is the issue of separating domestic communication from the rest, but
that's just something they have to deal with and US citizens have to be
paranoid about. This whole situation will probably result in better
supervision/monitoring of activities rather than stopping any of them
(i.e. simply more people in-the-know of what the NSA is up to).

That said, I am not a US citizen nor up-to-date on the details of this
ATT/NSA issue or the privacy implications, and I am sure enough of the US
folks here are.

Gadi.

Re: private ip addresses from ISP

[Edward B. DREGER]

RAS> Date: Tue, 23 May 2006 03:33:34 -0400
RAS> From: Richard A Steenbergen

RAS> If you're receiving RFC1918 sourced packets

#include "flamewars/urpf.h"
#include "flamewars/pmtud.h"


Eddy
--
Everquick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita

DO NOT send mail to the following addresses:
[EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED]
Sending mail to spambait addresses is a great way to get blocked.
Ditto for broken OOO autoresponders and foolish AV software backscatter.

Re: private ip addresses from ISP

[Richard A Steenbergen]

On Mon, May 22, 2006 at 04:30:37PM -0400, Andrew Kirch wrote:
> 
> > 3) You are seeing packets with source IPs inside private space
> > arriving at
> > your interface from your ISP?
...
> Sorry to dig this up from last week but I have to strongly disagree with
> point #3.  
> >From RFC 1918
>Because private addresses have no global meaning, routing information
>about private networks shall not be propagated on inter-enterprise
>links, and packets with private source or destination addresses
>should not be forwarded across such links. Routers in networks not
>using private address space, especially those of Internet service
>providers, are expected to be configured to reject (filter out)
>routing information about private networks.
> 
> The ISP shouldn't be "leaving" anything to the end-user, these packets
> should be dropped as a matter of course, along with any routing
> advertisements for RFC 1918 space(From #1). ISP's who leak 1918 space
> into my network piss me off, and get irate phone calls for their
> trouble.

The section you quoted from RFC1918 specifically addresses routes, not 
packets. If you're receiving RFC1918 *routes* from anyone, you need to 
thwack them over the head with a cluebat a couple of times until the cluey 
filling oozes out. If you're receiving RFC1918 sourced packets, for the 
most part you really shouldn't care. There are semi-legitimate reasons for 
packets with those sources addresses to float around the Internet, and 
they don't hurt anything. If you really can't stand seeing an RFC1918 
sourced packet over the Internet it is more of a personality problem than 
a networking problem, so a good shrink is probably going to be more useful 
than a good firewall.

-- 
Richard A Steenbergen <[EMAIL PROTECTED]>   http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)