NETCONF checkpoint

[Eliot Lear]

[replies to either the netconf list if you are a member or to me, and I 
will forward them *directly* to the netconf list unless instructed NOT 
to do so.]

Dear NANOG folk,

The NETCONF working group of the IETF is currently developing a 
collection of protocol specifications for the configuration of network 
elements.  This work originated from a roadshow that many of us went on 
to learn what operators of different types want in such a protocol.  Now 
we would like to checkpoint with you on some of the contents of those 
specifications.

What follows a highlight of two issues I believe are important to NANOG. 
 There are, however, many unresolved issues with NETCONF, some more 
important than others, that have been posted by the chair today to the 
netconf mailing list.  They can be viewed by going to 
http://ops.ietf.org/lists/netconf/netconf.2003.

The working group solicits your opinion on as many of these issues as 
you care to comment on.

The protocol itself is split into two parts: an abstract set of 
functions, and a binding to specific protocols, including SSH, BEEP, and 
SOAP over HTTP(s).  Each protocol has its pluses and minuses.

As envisioned, the base protocol supports an option for notifications. 
The idea is that a manager would be notified of configuration-related 
events, such as a card insertion or removal, and act appropriately to 
configure the element.  The envisioned format of notifications is either 
reliable syslog from RFC 3195 or something similar.  Because 
notifications are asynchronous, one writes code that implements a 
dispatch mechanism that discriminates on the type of event. 
Notifications would be an option that not all managers would have to 
implement.

Our first question is whether or not you are interested in receiving 
such notifications?  Related, do you use such a mechanism today?

The working group is attempting to determine whether notifications 
should remain as part of the base specification.  Here are the choices 
facing the group:

Option A.  Leave them in as currently specified, and require all 
protocol mappings to support them.
Option B.  Allow them to be asynchronous, but don't use RFC 3195, and 
require all mappings to support them.
Option C.  Remove them entirely from the specification and let vendors 
implement RFC 3195 or other notification mechanisms as they see fit (for 
instance, existing syslog).

Do you have an opinion on which of these options you would like?

Related, the NETCONF base protocol currently makes use of the notion of 
channels.  Channels are a basic concept in the BEEP protocol, and they 
exist in SSH as well.  However, use of multiple channels in SSH is not 
supported in common SSH applications.  They are completely absent in 
HTTP, and so the notion of a session would have to be introduced in the 
mapping.

Channels are a means of maintaining multiple communication streams
within a single session.  In NETCONF, there are three types of streams:
management, operations, and notifications.  Channels allow these 
different message types to be multiplexed within the same session 
without the need to interleave the messages in a way that preserves 
their integrity (e.g. valid XML instance documents).  NETCONF utilizes
channels to separate asynchronous messages (notifications or RPC 
progress reports) from normal operations, as well as separate high 
priority operations (RPC abort) from normal operations.

The working group has three choices:

Option A.  Keep channels in the base document and require each mapping 
to support them.
Option B.  Make channels optional.
Option C.  Remove channels from the base protocol and allow their use
   in the protocol bindings.

Which option do you prefer?

Again, these are important protocol issues that will affect your ability 
to build tools.  There are others.

If you would like to read the entire set of documents, you will find 
them by going to the NETCONF working group charter page:
http://www.ietf.org/html.charters/netconf-charter.html.

If there is sufficient interest we will seek another BOF at Miami.

Thanks for your help,

Eliot

2MB transatlantic feed enquiry

[paul]

I'm looking for a company whom can deliver a 2mb SDH, MPLS VPN, ATM or
10mb EoMPLS connection between Oregon/Salem and Telehouse North, London
Please contact me off list.


-- 
Paul Watson #  
Oninit Ltd  # Growing old is mandatory
Tel: +44 1436 672201# Growing up is optional
Fax: +44 1436 678693# 
Mob: +44 7818 003457#
www.oninit.com  #

AOL rejecting mail from IP's w/o reverse DNS ?

[Christopher X. Candreva]

Since I'm 99% sure the idea (or stupidity thereof :-) of blocking SMTP
servers without reverse DNS came up here in this discussion, I just ran a
manual queue run to clean out a queue, and saw this come up:

... Connecting to mailin-04.mx.aol.com. via esmtp...220-rly-xn05.mx.aol.com
ESMTP mail_relay_in-xn5.9; Wed, 03 Dec 2003 09:59:55
-0500
220-America Online (AOL) and its affiliated companies do not
220- authorize the use of its proprietary computers and computer
220- networks to accept, transmit, or distribute unsolicited bulk
220- e-mail sent from the internet.  Effective immediately:  AOL
220- may no longer accept connections from IP addresses which
220  have no reverse-DNS (PTR record) assigned.
>>> EHLO westnet.com

I don't know if this is new -- I don't recall seeing it before, but it
doesn't say they WILL refuse, just they may. If they do start blocking --
this WILL be an operational issue.


==
Chris Candreva  -- [EMAIL PROTECTED] -- (914) 967-7816
WestNet Internet Services of Westchester
http://www.westnet.com/

Re: AOL rejecting mail from IP's w/o reverse DNS ?

[Randy Bush]

> I don't know if this is new -- I don't recall seeing it before, but it
> doesn't say they WILL refuse, just they may. If they do start blocking --
> this WILL be an operational issue.

you're right.  it will be.  people will have to clean up their
in-addr.arpa.  or am i missing some reason they can't, other
than laziness?

randy

Re: AOL rejecting mail from IP's w/o reverse DNS ?

[Suresh Ramasubramanian]

Christopher X. Candreva  writes on 12/3/2003 10:13 AM:

Since I'm 99% sure the idea (or stupidity thereof :-) of blocking SMTP
servers without reverse DNS came up here in this discussion, I just ran a
manual queue run to clean out a queue, and saw this come up:
They have had this policy since several months now but it is still a 
"may" - and does give them a good excuse to take out large IP blocks 
that don't have proper reverse DNS assigned and emit a lot of spam.

More at http://postmaster.info.aol.com

If this is what it takes to push more people to get valid PTR records on 
their mailservers ...

I don't know if this is new -- I don't recall seeing it before, but it
doesn't say they WILL refuse, just they may. If they do start blocking --
this WILL be an operational issue.
Lots of mailservers (such as the one for freebsd.org) already do this.

I have not seen any large ISP other than AOL do this yet, though. 
However if they make it a "must" rather than a "may", I can see a whole 
lot of ISPs who will be quite eager to follow suit and do something on 
the same lines.

	srs

--
srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9
manager, outblaze.com security and antispam operations

Re: AOL rejecting mail from IP's w/o reverse DNS ?

[Christopher X. Candreva]

On Wed, 3 Dec 2003, Randy Bush wrote:

> you're right.  it will be.  people will have to clean up their
> in-addr.arpa.  or am i missing some reason they can't, other
> than laziness?

See, this is the war I didn't want to start again. Unless I'm thinking of a
discussion on a different list -- I was sure in the whole Verizon "spam
measures hurting other servers" thread, the whole blocking w/o IN PTR
records had come up, with people saying they were on hosting where they
couldn't change PTR records, and the clients who couldn't get mail from
small offices with Exchange servers on DSL lines where the ISP hadn't
configured reverse DNS . Then there was the comment on how reverse DNS was
meaningless, and did you still run identd ?

Maybe I'm thinking of the wrong list.

If AOL does it, in a way the question is moot. At least those of us who DO
know how to configure DNS can get some clients from the ones who don't.





==
Chris Candreva  -- [EMAIL PROTECTED] -- (914) 967-7816
WestNet Internet Services of Westchester
http://www.westnet.com/

Re: DS-3 test equipment

[Rick Ernst]

Replying with responses to my own post:

The overwhelming response was TTC/Acterna T-Berd with a couple of Digitial
Lightwaves thrown in, plus a hit each for Anritsu and Sunset.

Thanks for all the information.

Rick




On Tue, 2 Dec 2003, Rick Ernst wrote:

:>
:>
:>I've searched the archives and find some hits on DS-1 test gear, but I'm
:>looking for opinions/experience with DS-3 test gear.

Re: AOL rejecting mail from IP's w/o reverse DNS ?

[Suresh Ramasubramanian]

Randy Bush  writes on 12/3/2003 10:18 AM:

you're right.  it will be.  people will have to clean up their
in-addr.arpa.  or am i missing some reason they can't, other
than laziness?
Well - unless you have a /24, in-addr.arpa is typically under the 
control of your upstream provider.

And at least some few upstream providers I have seen over the past few 
years are ignorant of basic DNS principles, and don't know how to do 
proper delegation.

Their sending senior management off on junkets abroad, ostensibly to 
attend APNIC tutorials, seems to be a common cause.  The actual admins 
often remain untrained. Come to think of it, quite a few such ISPs don't 
know to do proper BGP or proper anything else either ...

If that is not the case, and the ISP does know to do reverse DNS, they 
often charge you $$$ for each line they add into their bind configs. 
One of the providers we were looking at (we were shopping for a /24) was 
 charging a rather high sum per line added to their bind configs.

What's more - their support was insisting that the config we sent them 
(just enough to let them delegate in-addr.arpa authority for the /24 to 
our nameservers) was "wrong".  They apparently were under the impression 
we were going to pay them for each IP in the /24, to add rDNS.

So, especially in countries where most if not all the IP providers you 
get are dumber than rocks, rDNS is often dismissed as an unnecessary 
luxury.  Especially when you have maybe one IP allocated for a colocated 
server, rather than a /24 or two.

	srs

--
srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9
manager, outblaze.com security and antispam operations

Re: AOL rejecting mail from IP's w/o reverse DNS ?

[Suresh Ramasubramanian]

Christopher X. Candreva  writes on 12/3/2003 10:42 AM:

discussion on a different list -- I was sure in the whole Verizon "spam
measures hurting other servers" thread, the whole blocking w/o IN PTR
records had come up, with people saying they were on hosting where they
couldn't change PTR records, and the clients who couldn't get mail from
That must be some other thread I think - one thread soon starts to look 
a lot like another, and I doubt if there's a single topic of this sort 
that hasn't been discussed to death already.

	srs

--
srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9
manager, outblaze.com security and antispam operations

Re: AOL rejecting mail from IP's w/o reverse DNS ?

[Daniel Senie]

At 10:42 AM 12/3/2003, Christopher X. Candreva wrote:

On Wed, 3 Dec 2003, Randy Bush wrote:

> you're right.  it will be.  people will have to clean up their
> in-addr.arpa.  or am i missing some reason they can't, other
> than laziness?
See, this is the war I didn't want to start again. Unless I'm thinking of a
discussion on a different list -- I was sure in the whole Verizon "spam
measures hurting other servers" thread, the whole blocking w/o IN PTR
records had come up, with people saying they were on hosting where they
couldn't change PTR records, and the clients who couldn't get mail from
small offices with Exchange servers on DSL lines where the ISP hadn't
configured reverse DNS . Then there was the comment on how reverse DNS was
meaningless, and did you still run identd ?
The issue I think AOL was getting at was not whether PTR records matched 
the A record for the host. That is indeed a can of worms, and there are 
reasons why that isn't a good idea, primarily because many people don't 
have access to the PTR records for smaller blocks or single addresses.

However, there are a great many hosts spewing email (spam, in most cases 
seen at our servers) that have no INADDR set up at all. It would indeed be 
helpful if there were reasonable PTR records everywhere, even if the PTR 
information didn't match the A record information. The PTR information 
could at least provide some clues as to the ISP involved, etc.


Maybe I'm thinking of the wrong list.

If AOL does it, in a way the question is moot. At least those of us who DO
know how to configure DNS can get some clients from the ones who don't.
Many will turn on a flag to specify "some PTR must exist" if AOL or some 
other large provider does it and is able to stick with it.

Yes, there'll be some work for DNS-clued consultants if that happens.

The impact on the 'net will not be all that significant, though. A few 
providers will certainly be impacted, namely those who've not bothered to 
implement (or only partially implement) INADDR.

MTU path discovery and IPSec

[jgraun]

Two questions:

1) I assume MTU path discovery has to been in enabled on each router in the path in 
order for it work correctly?!

2) Anybody use this to solve application issues over an IPSec tunnel to due to large 
of a frame?

any help would be great

Thanks

Re: AOL rejecting mail from IP's w/o reverse DNS ?

[Michael . Dillon]

>the whole blocking w/o IN PTR
>records had come up, 

Interestingly, there was a time when access to FTP servers
was considered important and many FTP servers blocked access
if the IN PTR records did not match the IN A records.

>with people saying they were on hosting where they
>couldn't change PTR records, and the clients who couldn't get mail from
>small offices with Exchange servers on DSL lines where the ISP hadn't
>configured reverse DNS.

Sometimes SMTP relaying is good. If your ISP has good reason
to not configure matching IN PTR records for your mail server
then ask them to relay all your outgoing SMTP. The end result
is the same; you won't be able to set up a working SMTP server
without your ISP's cooperation.

> Then there was the comment on how reverse DNS was
>meaningless, and did you still run identd ?

It's not the reverse DNS itself that is meaningful. It is the
fact that the SMTP server operator with proper IN PTR records
probably has the cooperation of their ISP.

Proper configuration of in-addr.arpa is a "good idea" TM.
However, it isn't the right way for large mail server operators
to go. Instead, they should start exchanging their SMTP sessions
on a port other than 25, i.e. NIMTP (New Improved MTP). The NIMTP
servers would not accept incoming connections from unknown servers.
In order to join the club, you would have to certify that you will
only send mail from known senders or relay mail from organizations
which will make the same certification. In this way, we create an
overlay mail transport network in which the members have some sort
of one-to-one mail peering relationship that allows them to enforce
an AUP on each other as well as maintain good contact info.

Peering relationships work for BGP (lots of rules) and they worked
for USENET (not many rules). Why can't the same principles be applied
to email or IM services?

--Michael Dillon

Re: AOL rejecting mail from IP's w/o reverse DNS ?

[Joe Abley]

On 3 Dec 2003, at 10:51, Suresh Ramasubramanian wrote:

Randy Bush  writes on 12/3/2003 10:18 AM:

you're right.  it will be.  people will have to clean up their
in-addr.arpa.  or am i missing some reason they can't, other
than laziness?
Well - unless you have a /24, in-addr.arpa is typically under the 
control of your upstream provider.
RFC2317.

So, especially in countries where most if not all the IP providers you 
get are dumber than rocks, rDNS is often dismissed as an unnecessary 
luxury.  Especially when you have maybe one IP allocated for a 
colocated server, rather than a /24 or two.
Maybe more people should do what AOL says they may do, then.

Joe

Re: MTU path discovery and IPSec

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes:
>
>Two questions:
>
>1) I assume MTU path discovery has to been in enabled on each router in the pa
>th in order for it work correctly?!

No -- it only has to be enabled on routers with smaller outbound MTUs 
than inbound.  A router for which all links have a 1500-byte MTU 
doesn't need path MTU discovery; it will never need to fragment 
anything.

--Steve Bellovin, http://www.research.att.com/~smb

Re: AOL rejecting mail from IP's w/o reverse DNS ?

[Suresh Ramasubramanian]

Joe Abley  writes on 12/3/2003 11:11 AM:

RFC2317.
that'd still involve the ISP inserting stuff in their nameservers.

when "isp admins" are substituted by "drones working out of templates / 
web forms" ...

ps - there's of course the rather umm... interesting content below ;)
http://homepages.tesco.net/~J.deBoynePollard/FGA/avoid-rfc-2317-delegation.html
Maybe more people should do what AOL says they may do, then.
I'm all in favor of it - but I'm still reluctant to dump legit mail 
that'll get dumped if I do this.  I'll have to be pushed a lot farther 
before I start doing this (and with spam levels increasing the way they 
are ...).

--
srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9
manager, outblaze.com security and antispam operations

Re: AOL rejecting mail from IP's w/o reverse DNS ?

[Petri Helenius]

[EMAIL PROTECTED] wrote:

Proper configuration of in-addr.arpa is a "good idea" TM.
However, it isn't the right way for large mail server operators
to go. Instead, they should start exchanging their SMTP sessions
on a port other than 25, i.e. NIMTP (New Improved MTP). The NIMTP
servers would not accept incoming connections from unknown servers.
In order to join the club, you would have to certify that you will
only send mail from known senders or relay mail from organizations
which will make the same certification. In this way, we create an
overlay mail transport network in which the members have some sort
of one-to-one mail peering relationship that allows them to enforce
an AUP on each other as well as maintain good contact info.
 

The system exactly like you describe already exists. It´s based on the 
standard
X.400 protocol and is available across the world. Or in some parts, used to
be. If that approach would be highly successful, why would it not prosper
instead of SMTP today?

Pete

Re: AOL rejecting mail from IP's w/o reverse DNS ?

[Pete Ehlke]

On Wed, Dec 03, 2003 at 11:28:19AM -0500, Suresh Ramasubramanian wrote:
> 
> ps - there's of course the rather umm... interesting content below ;)
> http://homepages.tesco.net/~J.deBoynePollard/FGA/avoid-rfc-2317-delegation.html
> 
Which is totally, completely wrong and causes, in both cases, servers to
leak name space (which causes cache poisoning) and, in once case,
servers to potentially be marked as lame. The man is flat out wrong.
Don't follow his advice.

-Pete

Re: MTU path discovery and IPSec

[Owen DeLong]

A subtle correction...

A router where all MTUs are the same will never have to fragement
anything.  A router where all MTUs are >=1500 will probably not
need to fragment anything.  However, it is possible to attach
a host via GIG-E or other media which supports jumbo frames
(Frame relay, for example) and need to fragment to support a
1500 octet MTU.  Currently, this would be a rare occurrence, but,
it is possible in some circumstances.  Eventually, if this assumption
were to circulate widely, it could have similar consequences to many
other errant assumptions on the internet.
Owen

--On Wednesday, December 3, 2003 11:19 AM -0500 "Steven M. Bellovin" 
<[EMAIL PROTECTED]> wrote:

In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
writes:
Two questions:

1) I assume MTU path discovery has to been in enabled on each router in
the pa th in order for it work correctly?!
No -- it only has to be enabled on routers with smaller outbound MTUs
than inbound.  A router for which all links have a 1500-byte MTU
doesn't need path MTU discovery; it will never need to fragment
anything.
		--Steve Bellovin, http://www.research.att.com/~smb




--
If it wasn't crypto-signed, it probably didn't come from me.


pgp0.pgp
Description: PGP signature

Re: MTU path discovery and IPSec

[Valdis . Kletnieks]

On Wed, 03 Dec 2003 16:05:39 GMT, [EMAIL PROTECTED]  said:

> 1) I assume MTU path discovery has to been in enabled on each router in the path in 
> order for it work correctly?!

Actually, no.  All that's required is that:

a) The router handle the case of a too-large packet with the DF bit set by
sending back an ICMP 'Dest Unreachable - Frag Needed' packet.  I've never
actually encountered a router that didn't get this part right. (Has anybody ever
seen a router botch this, *other* than a config error covered in (b) below?)

b) said ICMP makes it back to the originating machine.  This is where all the
operational breakage I've ever seen on PMTU Discovery comes from. And in almost
all cases, one of two things is at fault.  Either some bonehead firewall admin
is "blocking all ICMP for security" (fixable by reconfiguring the firewall to
let ICMP Frag Needed error messages through), or some bonehead network provider
numbered their point-to-points from 1918 space and the ICMP gets ingress/egress
filtered (this one is usually not fixable except with a baseball bat).



pgp0.pgp
Description: PGP signature

RE: AOL rejecting mail from IP's w/o reverse DNS ?

[Jeffrey Paul]

Perhaps I'm being naïve, but this seems like a very good way to cause spammers to 
suddenly start having valid PTR RRs.  Thoughts?

-j

--
Jeffrey Paul - [EMAIL PROTECTED] - (877) 748-3467
Senior Network Administrator, Diamond Financial Products

Re: AOL rejecting mail from IP's w/o reverse DNS ?

[Suresh Ramasubramanian]

Pete Ehlke  writes on 12/3/2003 11:38 AM:
On Wed, Dec 03, 2003 at 11:28:19AM -0500, Suresh Ramasubramanian wrote:

ps - there's of course the rather umm... interesting content below ;)
http://homepages.tesco.net/~J.deBoynePollard/FGA/avoid-rfc-2317-delegation.html
Which is totally, completely wrong and causes, in both cases, servers to
leak name space (which causes cache poisoning) and, in once case,
servers to potentially be marked as lame. The man is flat out wrong.
Don't follow his advice.
The ;) smiley and that "umm..." before the "interesting" were added for 
precisely that reason.  Sorry if I was not too clear.

And there should be an "as usual" after your "flat out wrong", I think.

--
srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9
manager, outblaze.com security and antispam operations

Re: AOL rejecting mail from IP's w/o reverse DNS ?

[Michael . Dillon]

>The system exactly like you describe already exists. It´s based on the 
>standard
>X.400 protocol and is available across the world.

Wrong.
X.400 is immensely more complex than a federation of ISPs using
SMTP on another port number.

>Or in some parts, used to
>be. If that approach would be highly successful, why would it not prosper
>instead of SMTP today?

X.400 didn't work for a variety of reasons such as
incomprehensible email addresses, too much complexity,
the need to run X.500 directory services, the high cost
of registering an X.500 organization identifier and the
lack of open-source software.

Internet mail systems have borrowed good bits from
X.400 in the past such as the lighweight variant of
X.500 known as LDAP. But peering agreements are not
something that was invented by the X.400 committee.

Lots of people now realize that there needs to be
some system for incoporating "trust" into the Internet
mail system so that mail servers can make decisions
on whether or not to trust incoming messages. I think
that X.400 is the wrong way to go when we can solve the
problem more simply by shifting large amounts of SMTP
traffic onto another port number based on one-to-one
peering agreements between the organizations using that
port number.

Example. Lets say that AOL, Verizon and MSN agree to try
this approach. On day one, they would only reroute email
originating with their customers to the NIMTP port. On day 2
they would start to certify some of the ISPs who send large
amounts of email to AOL, Verizon or MSN. Those ISPs would
only divert email from their own customers to NIMTP. Then
on day 3, these smaller ISPs would begin to certify some
of their peers and smaller local ISPs for NIMTP. On day 3
these smaller ISPs will divert AOL-destined email to the
NIMTP relay of the day 2 ISPs who will then pass it on
to AOL, Verizon or MSN. 

If SPAM shows up somewhere, AOL knows who to call because 
they exchanged that info as part of the peering agreement.
The Day 2 ISP fixes the problem by cutting off the NIMTP
peering with the culprit and then getting them to cut off
the spammers. This can all happen within a couple of hours
of a spam email appearing. Ideally, this mesh of NIMTP peers
will only have 4 or 5 relay hops between the smallest mail
servers and the biggest ones. In today's world that means
it might take 5 times as long to deliver a message, i.e. it
will take five minutes rather than one minute.

The NIMTP peers will no doubt hone the system to include
various forms of automated checks and notifications but that's
not important on day 1. The important thing is to set down
the ground rules for NIMTP peering and that can only be done
by human beings working for some of the larger users of email.

--Michael Dillon

Re: AOL rejecting mail from IP's w/o reverse DNS ?

[Greg Maxwell]

On Wed, 3 Dec 2003 [EMAIL PROTECTED] wrote:

[snip]
> Peering relationships work for BGP (lots of rules) and they worked
> for USENET (not many rules). Why can't the same principles be applied
> to email or IM services?

Where is NickC when you need him... this sounds like something out of his
layer4 nap idea...

Seriously, do we really need SMTP peering agreements?  I don't know of too
many places that are UUCPing their email... SMTP traffic already crosses
(BGP) peering agreement controlled links. If putting contractional
obligations there fails to work why should we believe some new and less
understood system would be any more effective?

RE: MTU path discovery and IPSec

[cproctor]

The problem is described pretty clearly at
http://www.cisco.com/warp/public/105/56.html.The issue I have
experienced is that fragmentation can lead to performance impacts that are
unacceptable.  

I wish we could start a clue campaign informing people why ICMP should not
be summarily dumped at the firewall.

Chris Proctor
EPIK Communications

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, December 03, 2003 11:39 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: MTU path discovery and IPSec 
> 
> On Wed, 03 Dec 2003 16:05:39 GMT, [EMAIL PROTECTED]  said:
> 
> > 1) I assume MTU path discovery has to been in enabled on 
> each router in the path in order for it work correctly?!
> 
> Actually, no.  All that's required is that:
> 
> a) The router handle the case of a too-large packet with the 
> DF bit set by
> sending back an ICMP 'Dest Unreachable - Frag Needed' packet. 
>  I've never
> actually encountered a router that didn't get this part 
> right. (Has anybody ever
> seen a router botch this, *other* than a config error covered 
> in (b) below?)
> 
> b) said ICMP makes it back to the originating machine.  This 
> is where all the
> operational breakage I've ever seen on PMTU Discovery comes 
> from. And in almost
> all cases, one of two things is at fault.  Either some 
> bonehead firewall admin
> is "blocking all ICMP for security" (fixable by reconfiguring 
> the firewall to
> let ICMP Frag Needed error messages through), or some 
> bonehead network provider
> numbered their point-to-points from 1918 space and the ICMP 
> gets ingress/egress
> filtered (this one is usually not fixable except with a baseball bat).
> 
> 

Re: AOL rejecting mail from IP's w/o reverse DNS ?

[Suresh Ramasubramanian]

Jeffrey Paul  writes on 12/3/2003 11:39 AM:

Perhaps I'm being naïve, but this seems like a very good way to cause spammers to suddenly start having valid PTR RRs.  Thoughts?

A lot of spam these days comes from trojaned windows machines on dialup 
/ broadband IPs.

Most ISPs in the USA and the world over already have generic PTR records 
(ip-foo-bar.ppp.provider.net and such) on their dhcp pools.

So, yes, the mere presence of rDNS for an IP is not an indicator that 
the traffic coming at your mailserver from that IP is not spam.

On the other hand, the absence of rDNS on an IP seems to often be 
accompanied by assorted other brokenness, such as open relays / proxies 
and compromised hosts.

--
srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9
manager, outblaze.com security and antispam operations

Re: AOL rejecting mail from IP's w/o reverse DNS ?

[Suresh Ramasubramanian]

Greg Maxwell  writes on 12/3/2003 11:39 AM:

Seriously, do we really need SMTP peering agreements?  I don't know of too
many places that are UUCPing their email... SMTP traffic already crosses
(BGP) peering agreement controlled links. If putting contractional
obligations there fails to work why should we believe some new and less
understood system would be any more effective?
What about speaking plain old smtp, but with transport / mailertable 
rules routing all  mail for domain X (say AOL or MSN) to "special 
access" servers that have firewall ACLs allowing only connections from a 
restricted set of IPs?

So AOL talks to (say) us and says "hey, instead of  mail from our users 
waiting like all other  mail to connect to port 25 on your MXs, set 
aside a cluster of MXs that'll permit smtp connections from [this /24]"

We then take these emails and deliver them as usual.  Just that AOL mail 
to our users gets delivered faster, doesn't clutter our MXs ... and we 
can send mail to AOL over a similar back channel.

As a bonus, monitoring and controlling spam on these would be far easier.

Yes it won't scale.  But it is not intended to scale - it is just 
intended to be a series of agreements between large providers that will -

* reduce congestion / endless mail queues on regular MXs / outbound 
machines.

* let inbound / outbound flowing through that back channel get more 
easily managed [and monitored for spam] than if it were to take the 
usual route.

Think of it as taking a short cut through a toll road instead of the 
usual toll free traffic jammed highway.

	srs

--
srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9
manager, outblaze.com security and antispam operations

Re: AOL rejecting mail from IP's w/o reverse DNS ?

[Dave Howe]

Jeffrey Paul wrote:
> Perhaps I'm being naïve, but this seems like a very good way to cause
> spammers to suddenly start having valid PTR RRs.  Thoughts?
or limiting attacks for relay/proxy/trojan purposes targets that have valid
PTR records which of course ideally should be all of them.

Re: AOL rejecting mail from IP's w/o reverse DNS ?

[Robert E. Seastrom]

Daniel Senie <[EMAIL PROTECTED]> writes:

> Many will turn on a flag to specify "some PTR must exist" if AOL or
> some other large provider does it and is able to stick with it.
> 
> Yes, there'll be some work for DNS-clued consultants if that happens.
> 
> The impact on the 'net will not be all that significant, though. A few
> providers will certainly be impacted, namely those who've not bothered
> to implement (or only partially implement) INADDR.

... and it will be a zero-sum game once the spammers (or their
complicit ISPs) fix their in-addrs too.

while i applaud the notion that people will fix their dns entries,
we're long past the days where spammers could be assumed to be
clueless twits who were operating without serious technical backing.

making the presumed good guys fix their in-addrs will have the
collateral effect of getting them fixed by the spammers too.  in fact,
i wouldn't be surprised if some of the spammers who subscribe to nanog
have new to-do items on their whiteboards now.

---rob

Re: AOL rejecting mail from IP's w/o reverse DNS ?

[Adam McKenna]

On Wed, Dec 03, 2003 at 08:38:10AM -0800, Pete Ehlke wrote:
> 
> On Wed, Dec 03, 2003 at 11:28:19AM -0500, Suresh Ramasubramanian wrote:
> > 
> > ps - there's of course the rather umm... interesting content below ;)
> > http://homepages.tesco.net/~J.deBoynePollard/FGA/avoid-rfc-2317-delegation.html
> > 
> Which is totally, completely wrong and causes, in both cases, servers to
> leak name space (which causes cache poisoning) and, in once case,
> servers to potentially be marked as lame. The man is flat out wrong.
> Don't follow his advice.

How can delegating in-addr.arpa on a per-ip basis be any different or worse
than delegating it using an rfc2317 scheme?

--Adam

Re: MTU path discovery and IPSec

[David Sinn]

Do not just blame random company's firewall's for dumping ICMP.  There are
some very well known hosting groups that filter ICMP on edge of their
network's in their routers.

It gets even worse when their server admin's decide to leave PMTU discovery
on.  Sort of defeats the purpose...

Given the nastiness of ICMP DDoS attacks of late, it might be better to hit
the server and client admin's with the clue bat about not using PMTU
discovery (which also extends to the writers of the App's and OS's).  Frag.
is in the fast path of just about every current version of brand C code, so
giving the tunneling folks the OK to frag the packet might be preferred to
forcing them to mess about with alternate options.

David

On 12/3/03 8:59 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

> 
> The problem is described pretty clearly at
> http://www.cisco.com/warp/public/105/56.html.The issue I have
> experienced is that fragmentation can lead to performance impacts that are
> unacceptable.  
> 
> I wish we could start a clue campaign informing people why ICMP should not
> be summarily dumped at the firewall.
> 
> Chris Proctor
> EPIK Communications
> 
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, December 03, 2003 11:39 AM
>> To: [EMAIL PROTECTED]
>> Cc: [EMAIL PROTECTED]
>> Subject: Re: MTU path discovery and IPSec
>> 
>> On Wed, 03 Dec 2003 16:05:39 GMT, [EMAIL PROTECTED]  said:
>> 
>>> 1) I assume MTU path discovery has to been in enabled on
>> each router in the path in order for it work correctly?!
>> 
>> Actually, no.  All that's required is that:
>> 
>> a) The router handle the case of a too-large packet with the
>> DF bit set by
>> sending back an ICMP 'Dest Unreachable - Frag Needed' packet.
>>  I've never
>> actually encountered a router that didn't get this part
>> right. (Has anybody ever
>> seen a router botch this, *other* than a config error covered
>> in (b) below?)
>> 
>> b) said ICMP makes it back to the originating machine.  This
>> is where all the
>> operational breakage I've ever seen on PMTU Discovery comes
>> from. And in almost
>> all cases, one of two things is at fault.  Either some
>> bonehead firewall admin
>> is "blocking all ICMP for security" (fixable by reconfiguring
>> the firewall to
>> let ICMP Frag Needed error messages through), or some
>> bonehead network provider
>> numbered their point-to-points from 1918 space and the ICMP
>> gets ingress/egress
>> filtered (this one is usually not fixable except with a baseball bat).
>> 
>> 

Re: AOL rejecting mail from IP's w/o reverse DNS ?

[Randy Bush]

> ... and it will be a zero-sum game once the spammers (or their
> complicit ISPs) fix their in-addrs too.

'cept the in-addr.arps space from which they are coming has to be
populated.  i.e., no more connects from black holes.

randy

Re: AOL rejecting mail from IP's w/o reverse DNS ?

[Randy Bush]

> How can delegating in-addr.arpa on a per-ip basis be any different or worse
> than delegating it using an rfc2317 scheme?

consider the label of the ns rr to delegate only 1.2.3.42

Re: AOL rejecting mail from IP's w/o reverse DNS ?

[Michael . Dillon]

>What about speaking plain old smtp, but with transport / mailertable 
>rules routing all  mail for domain X (say AOL or MSN) to "special 
>access" servers that have firewall ACLs allowing only connections from a 
>restricted set of IPs?

If it's behind a firewall, then it's not on the Internet.
Since NIMTP is a proposal for improving Internet email,
then I think a new port number is in order. However, anyone
is free to implement NIMTP peering by using a firewall to
redirect new-port-number traffic to port 25 on some
existing mail servers if that suits their purposes.

NIMTP is lightweight technically, i.e. no new code
needed, just reconfigure things a bit. The real solution
resides in the agreements and the AUP that they will
enforce and that has to be hashed out by the people 
who run mail services at the large ISPs. Not by the BGP
peering folks and not by the IETF and not by the
anti-spammer brigade.

--Michael Dillon

Re: AOL rejecting mail from IP's w/o reverse DNS ?

[Adam McKenna]

On Wed, Dec 03, 2003 at 09:48:44AM -0800, Randy Bush wrote:
> > How can delegating in-addr.arpa on a per-ip basis be any different or worse
> > than delegating it using an rfc2317 scheme?
> 
> consider the label of the ns rr to delegate only 1.2.3.42

Do you mean ns.42.3.2.1.in-addr.arpa?  I still don't see what's wrong with
the following, or how it leads to cache poisoning or leaky name space.

42.3.2.1.in-addr.arpa IN NS ns.42.3.2.1.in-addr.arpa.
ns.42.3.2.1.in-addr.arpa IN A 5.6.7.86

--Adam

Re: AOL rejecting mail from IP's w/o reverse DNS ?

[Matthew Crocker]

On Dec 3, 2003, at 10:42 AM, Christopher X. Candreva wrote:

On Wed, 3 Dec 2003, Randy Bush wrote:

you're right.  it will be.  people will have to clean up their
in-addr.arpa.  or am i missing some reason they can't, other
than laziness?
See, this is the war I didn't want to start again. Unless I'm thinking 
of a
discussion on a different list -- I was sure in the whole Verizon "spam
measures hurting other servers" thread, the whole blocking w/o IN PTR
records had come up, with people saying they were on hosting where they
couldn't change PTR records, and the clients who couldn't get mail from
small offices with Exchange servers on DSL lines where the ISP hadn't
configured reverse DNS . Then there was the comment on how reverse DNS 
was
meaningless, and did you still run identd ?

AOL says the PTR record needs to be assigned.  It doesn't specify it 
has to match the @domain.com in the MAIL FROM: header.  Wouldn't it be 
enough to make sure every IP address you announce has a PTR and 
matching A record?  Hasn't this been a requirement for MANY services 
for MANY years?

--
Matthew S. Crocker
Crocker Communications, Inc.
Vice President
PO BOX 710
Greenfield, MA 01302
P: 413-746-2760
F: 413-746-3704
W: http://www.crocker.com
E: [EMAIL PROTECTED]

BEGIN:VCARD
VERSION:3.0
N:Crocker;Matthew;;;
FN:Matthew Crocker
ORG:Crocker Communications\, Inc.;
TITLE:Vice President
EMAIL;type=INTERNET;type=HOME;type=pref:[EMAIL PROTECTED]
EMAIL;type=INTERNET;type=HOME:[EMAIL PROTECTED]
TEL;type=HOME;type=pref:413 746-2760
item1.ADR;type=WORK;type=pref:;;1 Federal Street\nBuilding 102-2;Springfield;MA;01105;United States
item1.X-ABADR:us
item2.ADR;type=WORK:;;PO Box 710;Greenfield;MA;01302;United States
item2.X-ABADR:us
URL:http://www.crocker.com
X-AIM;type=HOME;type=pref:aiiyyeee
PHOTO;BASE64:
  TU0AKggAFAD+AAQBAAEAAAMBADEBAAMBADECAAMD
  /gEDAAMBAAEAAAEGAAMBAAIAAAERAAQBAAA9rgEVAAMBAAMAAAEWAAMB
  ADEXAAQBAAAbAAEaAAUBAAABBAEbAAUBAAABDAEcAAMBAAEAAAEoAAMA
  AAABAAIAAAExAAIUAAABFAEyAAIUAAABKAK8AAEAABIpAAABPIZJAAEAACggAAATZodp
  AAQBAABYsIdzAAcAAAIoAAA7hgAACAAIAAgACvynEAAK/IAAACcQQWRvYmUgUGhv
  dG9zaG9wIDcuMAAyMDAyOjA2OjE5IDExOjExOjQyADw/eHBhY2tldCBiZWdpbj0n77u/JyBpZD0n
  VzVNME1wQ2VoaUh6cmVTek5UY3prYzlkJz8+Cjw/YWRvYmUteGFwLWZpbHRlcnMgZXNjPSJDUiI/
  Pgo8eDp4YXBtZXRhIHhtbG5zOng9J2Fkb2JlOm5zOm1ldGEvJyB4OnhhcHRrPSdYTVAgdG9vbGtp
  dCAyLjguMi0zMywgZnJhbWV3b3JrIDEuNSc+CjxyZGY6UkRGIHhtbG5zOnJkZj0naHR0cDovL3d3
  dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIycgeG1sbnM6aVg9J2h0dHA6Ly9ucy5h
  ZG9iZS5jb20vaVgvMS4wLyc+CgogPHJkZjpEZXNjcmlwdGlvbiBhYm91dD0ndXVpZDphOTU4ZDk1
  Ni04NTA3LTExZDYtOWQyNC1mYWJiZDFhN2M3ZGInCiAgeG1sbnM6eGFwTU09J2h0dHA6Ly9ucy5h
  ZG9iZS5jb20veGFwLzEuMC9tbS8nPgogIDx4YXBNTTpEb2N1bWVudElEPmFkb2JlOmRvY2lkOnBo
  b3Rvc2hvcDo4OTM3MDRkYS04NTA2LTExZDYtOWQyNC1mYWJiZDFhN2M3ZGI8L3hhcE1NOkRvY3Vt
  ZW50SUQ+CiA8L3JkZjpEZXNjcmlwdGlvbj4KCjwvcmRmOlJERj4KPC94OnhhcG1ldGE+CiAgICAg
  ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
  ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg
  ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
  ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
  ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
  ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
  ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK
  ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
  ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg
  ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
  ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg
  ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
  ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
  ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
  ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
  ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg
  ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
  ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg
  ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
  ICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
  ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
  ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
  ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg
  ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
  ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg
  ICAgICAgICAgICAgICAgICAgICAgICAg

Re: AOL rejecting mail from IP's w/o reverse DNS ?

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, Matthew Crocker 

>>
>
>AOL says the PTR record needs to be assigned.  It doesn't specify it 
>has to match the @domain.com in the MAIL FROM: header.  Wouldn't it be 
>enough to make sure every IP address you announce has a PTR and 
>matching A record?  Hasn't this been a requirement for MANY services 
>for MANY years?


Right -- and then folks will start creating wildcard PTR records...


--Steve Bellovin, http://www.research.att.com/~smb

Re: AOL rejecting mail from IP's w/o reverse DNS ?

[Christopher X. Candreva]

On Wed, 3 Dec 2003, Robert E. Seastrom wrote:

> ... and it will be a zero-sum game once the spammers (or their
> complicit ISPs) fix their in-addrs too.

I disagree. I don't think the spammers, by and large, 'own' their IP
addresses. They are using (as someone said) hijacked space, or compromised
machines.

Odds are since many of these machines aren't SUPPOSED to be sending mail in
the first place, no one is going to complain, so nothing is going to be done
about them.


==
Chris Candreva  -- [EMAIL PROTECTED] -- (914) 967-7816
WestNet Internet Services of Westchester
http://www.westnet.com/

Re: AOL rejecting mail from IP's w/o reverse DNS?

[Dave Temkin]

You mean like Level3?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Steven M. Bellovin
Sent: Wednesday, December 03, 2003 2:27 PM
To: Matthew Crocker
Cc: Christopher X. Candreva; [EMAIL PROTECTED]
Subject: Re: AOL rejecting mail from IP's w/o reverse DNS ?



In message <[EMAIL PROTECTED]>, Matthew
Crocker

>>
>
>AOL says the PTR record needs to be assigned.  It doesn't specify it
>has to match the @domain.com in the MAIL FROM: header.  Wouldn't it be
>enough to make sure every IP address you announce has a PTR and
>matching A record?  Hasn't this been a requirement for MANY services
>for MANY years?


Right -- and then folks will start creating wildcard PTR records...


--Steve Bellovin, http://www.research.att.com/~smb



-- 
David Temkin

RE: AOL rejecting mail from IP's w/o reverse DNS?

[Michael Hallgren]

> 
> You mean like Level3?
> 

Well,... proxying (in any shape) should, hopefully, not happen prior to
having a decent downstream trust relation onboard... (?)...

mh


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Steven M. Bellovin
> Sent: Wednesday, December 03, 2003 2:27 PM
> To: Matthew Crocker
> Cc: Christopher X. Candreva; [EMAIL PROTECTED]
> Subject: Re: AOL rejecting mail from IP's w/o reverse DNS ?
> 
> 
> 
> In message <[EMAIL PROTECTED]>, Matthew
> Crocker
> 
> >>
> >
> >AOL says the PTR record needs to be assigned.  It doesn't specify it
> >has to match the @domain.com in the MAIL FROM: header.  Wouldn't it be
> >enough to make sure every IP address you announce has a PTR and
> >matching A record?  Hasn't this been a requirement for MANY services
> >for MANY years?
> 
> 
> Right -- and then folks will start creating wildcard PTR records...
> 
> 
>   --Steve Bellovin, http://www.research.att.com/~smb
> 
> 
> 
> -- 
> David Temkin
> 
> 

Re: AOL rejecting mail from IP's w/o reverse DNS ?

[Adi Linden]

> AOL says the PTR record needs to be assigned.  It doesn't specify it 
> has to match the @domain.com in the MAIL FROM: header.  Wouldn't it be 
> enough to make sure every IP address you announce has a PTR and 
> matching A record?  Hasn't this been a requirement for MANY services 
> for MANY years?

Requiring the PTR record to match the MAIL FROM: header would be horrific. 
There goes any hope of virtual hosting of mail accounts, i.e. one server 
with one ip handling multiple email domains. 

Adi

Firewall stateful handling of ICMP packets

[Sean Donelan]

You could drop ICMP packets at your firewall if the firewalls properly
implemented stateful inspection of ICMP packets.  The problem is few
firewalls include ICMP responses in their statefull analysis.  So you are
left with two bad choices, permit "all" ICMP packets or deny "all" ICMP
packets.

new nasty email virus trick to bypass scanners

[Mike Tancsa]

OK, here is a nasty virus trick.  The message gets sent in a password 
protected zip file.  The text of the messages says here are my pics and 
enter in the passwd  to view the archive.

The big problem is that normal avscanners cannot open the zip file to scan 
the contents since it is password protected.

However, the user can be easily socially engineered to open the file and 
blam.  The text of the message is nice and enticing making it look like 
private email with dirty pictures accidentally sent to the user...

---Mike

Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,[EMAIL PROTECTED]
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

Re: new nasty email virus trick to bypass scanners

[J. Oquendoy]

> However, the user can be easily socially engineered to open the file and
> blam.  The text of the message is nice and enticing making it look like
> private email with dirty pictures accidentally sent to the user...



Someone should create some form of standard 'README' document for the
layperson using the internet in regards to viruses, maybe template it and
send it to ISP's, so when new users sign up, they'll have a `slight' clue
as to why they're now getting those "RPC WARNING YOUR COMPUTER WILL SHUT
DOWN IN 60 SECOND" messages.

Then again many people wouldn't read it, unless of course an ISP stated
something silly to the extent that 'You will be held responsible* * *", of
which would be a horrible policy. It would be a nice thing for both the
user, and the network engineers/admins to have something in place to
minizmize the reach of viruses and trojans.

Hell it would have been nice for MS to invest in creating safer products
as opposed to paying `bounty hunters'.



=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
GPG Key ID 0x51F9D78D
Fingerprint 2A48 BA18 1851 4C99 CA22 0619 DB63 F2F7 51F9 D78D

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x51F9D78D

sil @ politrix . orghttp://www.politrix.org
sil @ infiltrated . net http://www.infiltrated.net

"I watch gangster flicks and root for the bad guy
and turn it off before it ends because the bad guy dies"
50 Cents -  'Assassins'

This is a farce confidential disclaimer intended to make you
aware that even though this may be priveledged information,
being it will become Google cache in the future, my original
intentions of keeping this message restricted and/or private
are thrown out the door. If you have received this e-mail in
error, please enjoy this signature and destroy this message
by dousing it in gasoline.

Re: MTU path discovery and IPSec

[Owen DeLong]

--On Wednesday, December 3, 2003 11:39 AM -0500 [EMAIL PROTECTED] 
wrote:

On Wed, 03 Dec 2003 16:05:39 GMT, [EMAIL PROTECTED]  said:

1) I assume MTU path discovery has to been in enabled on each router in
the path in order for it work correctly?!
Actually, no.  All that's required is that:

a) The router handle the case of a too-large packet with the DF bit set by
sending back an ICMP 'Dest Unreachable - Frag Needed' packet.  I've never
actually encountered a router that didn't get this part right. (Has
anybody ever seen a router botch this, *other* than a config error
covered in (b) below?)
When you consider that most firewalls are technically routers (albeit
somewhat pathological routers), yes... Many firewalls fail to send back
the ICMP and silently drop the DF packet.
b) said ICMP makes it back to the originating machine.  This is where all
the operational breakage I've ever seen on PMTU Discovery comes from. And
in almost all cases, one of two things is at fault.  Either some bonehead
firewall admin is "blocking all ICMP for security" (fixable by
reconfiguring the firewall to let ICMP Frag Needed error messages
through), or some bonehead network provider numbered their
point-to-points from 1918 space and the ICMP gets ingress/egress filtered
(this one is usually not fixable except with a baseball bat).
Yep... Those are definitely the most common PMTU-D problems.

Owen



--
If it wasn't crypto-signed, it probably didn't come from me.


pgp0.pgp
Description: PGP signature

Re: Firewall stateful handling of ICMP packets

[Owen DeLong]

Actually, any halfway decent firewall allows you to permit certain ICMP
type codes while rejecting others.  Not a perfect solution, but, for the
most part, there aren't a lot of fragmentation-needed exploits running
around.  (In fact, I'm hard pressed to imagine how a Frag needed packet
for an invalid session could do much of anything).
Owen

--On Wednesday, December 3, 2003 5:12 PM -0500 Sean Donelan 
<[EMAIL PROTECTED]> wrote:



You could drop ICMP packets at your firewall if the firewalls properly
implemented stateful inspection of ICMP packets.  The problem is few
firewalls include ICMP responses in their statefull analysis.  So you are
left with two bad choices, permit "all" ICMP packets or deny "all" ICMP
packets.




--
If it wasn't crypto-signed, it probably didn't come from me.


pgp0.pgp
Description: PGP signature

Does any know where the link is for

[Richard Irving]

 I seem to recall someone doing a paper on
ICMP and traceroute -at times-, as not always being indicative of
actual network performance...
 Does anyone remember who, or where,
that link is ?
Thanks in Advance.

:)

Re: Firewall stateful handling of ICMP packets

[Henry Linneweh]

there are expert modes where you can apply the
name source destination protocol time comments.  rank state action track
for more stabilized dedicated connections
 
I am certain there are more depending on the vender
 
-Henry
Sean Donelan <[EMAIL PROTECTED]> wrote:
You could drop ICMP packets at your firewall if the firewalls properlyimplemented stateful inspection of ICMP packets. The problem is fewfirewalls include ICMP responses in their statefull analysis. So you areleft with two bad choices, permit "all" ICMP packets or deny "all" ICMPpackets.

Re: Does any know where the link is for

[Richard Irving]

John Starta wrote:
If you locate this, please forward the link along.
  I haven't found the original, it was dated about
97-99... NLANR, perhaps  
 But, there are more recent write ups...

Here are two I encountered:

 

 This one explains why PING -may- be bad, but regular
performance, OK...
(Call it the end user explanation of ACL-CAR intervention)

 :)

And this one,( more what I was looking for..)
a detailed explanation of the caveats of clever
tracerouting providing Bogus Data.


 I needed something for a rookie tech who was "whining"
about a site tracerouting with an intervening router
- appearing - slow (An exchange BGP router, go figure),
but an end to end of -38 ms-, -consistent- and with -no- loss.
  He didn't believe the explanation of the BGP rumble...
and I was growing frustrated with the need for detail,
when it just wasn't registering !
  :(

 "When the Judge is a blind man, it can be -exasperating-
trying defend your choice of the Winner of the Art fair."
  :P

Re: Does any know where the link is for

[Richard Irving]

Richard Irving wrote:

...Oooops...

  "When the Judge is a blind man, it can be -exasperating-
 trying _to_ defend your choice of the Winner of the Art fair."
   :P

And to that I add the Maxim:

 "The probability of a Typo is in inverse proportion of
the time spent composing, and in direct proportion
to the level of frustration inherent in the author."
  :D

Re: AOL rejecting mail from IP's w/o reverse DNS ?

[Adam McKenna]

On Wed, Dec 03, 2003 at 09:53:37AM -0800, Adam McKenna wrote:
> 
> On Wed, Dec 03, 2003 at 09:48:44AM -0800, Randy Bush wrote:
> > > How can delegating in-addr.arpa on a per-ip basis be any different or worse
> > > than delegating it using an rfc2317 scheme?
> > 
> > consider the label of the ns rr to delegate only 1.2.3.42
> 
> Do you mean ns.42.3.2.1.in-addr.arpa?  I still don't see what's wrong with
> the following, or how it leads to cache poisoning or leaky name space.
> 
> 42.3.2.1.in-addr.arpa IN NS ns.42.3.2.1.in-addr.arpa.
> ns.42.3.2.1.in-addr.arpa IN A 5.6.7.86

Eight hours later, and I'm still waiting for a reply on this.  Were the
original attacks by Pete Ehlke warranted, or would he care to retract his
statements?

--Adam

Re: new nasty email virus trick to bypass scanners

[Mike Tancsa]

At 05:52 PM 03/12/2003, J. Oquendoy wrote:
Hell it would have been nice for MS to invest in creating safer products
as opposed to paying `bounty hunters'.
This is a total social engineering issue... Not much different than the 
"wallet inspector" asking to check your wallet.  More clever, but the same 
thing in the end.

---Mike 

Re: new nasty email virus trick to bypass scanners

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, Mike Tancsa writes:
>
>
>OK, here is a nasty virus trick.  The message gets sent in a password 
>protected zip file.  The text of the messages says here are my pics and 
>enter in the passwd  to view the archive.
>
Is this in the wild yet?  Any other details worth looking for?  
Symantec's AV site apparently has nothing on it.

--Steve Bellovin, http://www.research.att.com/~smb

Re: Firewall stateful handling of ICMP packets

[Jamie Reid]

Personal view: 

This was a problem when filtering Nachi while it pinged networks
to their knees. 

Sometimes I wonder if there is any legitimate reason to allow 
pings from users at all. If the user really needed to use
ping, that is, if they were in a position to do anything about the
results of the ping tests, then they would know enough to 
use traceroute in UDP mode or some other tool. 

There are lots of other useful ICMP types to handle all
the other ICMP needs, but ping seems to be something
that was created for the convenience of a kind of user
that is effectively extinct in todays Internet.  

ICMP echo is unique among ICMP types in that it is the
only one that elicits it's own response. What I mean by
this is that source-quench, -unreachables, and others
are all generated by hosts and routers in response to 
relatively stateful traffic. There is nothing that echos
do that SNMP (I know, I know) and traceroute don't
accomplish in a more controlled fashion, no? 

It would kill alot of DDoS attacks and render their zombie 
networks useless, retire legacy backdoors and viruses, up 
the ante for network management tools, and slow down
some virus propagation substantially. 

ICMP echos are a bit of a hack and, quite literally, noise, 
and I wonder if it may be time to consider unofficially 
retiring them using filters. 



 



--
Jamie.Reid, CISSP, [EMAIL PROTECTED]
Senior Security Specialist, Information Protection Centre 
Corporate Security, MBS  
416 327 2324 
>>> "Sean Donelan" <[EMAIL PROTECTED]> 12/03/03 05:12pm >>>


You could drop ICMP packets at your firewall if the firewalls properly
implemented stateful inspection of ICMP packets.  The problem is few
firewalls include ICMP responses in their statefull analysis.  So you are
left with two bad choices, permit "all" ICMP packets or deny "all" ICMP
packets.





 
Personal view: 
 
This was a problem when filtering Nachi while it pinged 
networks
to their knees. 
 
Sometimes I wonder if there is any legitimate reason to allow 

pings from users at all. If the user really needed to 
use
ping, that is, if they were in a position to do anything about 
the
results of the ping tests, then they would know enough to 

use traceroute in UDP mode or some other tool. 

 
There are lots of other useful ICMP types to handle 
all
the other ICMP needs, but ping seems to be 
something
that was created for the convenience of a kind of 
user
that is effectively extinct in todays Internet.  

 
ICMP echo is unique among ICMP types in that it is 
the
only one that elicits it's own response. What I mean 
by
this is that source-quench, -unreachables, and 
others
are all generated by hosts and routers in response to 

relatively stateful traffic. There is nothing that 
echos
do that SNMP (I know, I know) and traceroute 
don't
accomplish in a more controlled fashion, no? 
 
It would kill alot of DDoS attacks and render their 
zombie 
networks useless, retire legacy backdoors and viruses, up 
the ante for network management tools, and 
slow down
some virus propagation substantially. 
 
ICMP echos are a bit of a hack and, quite literally, 
noise, 
and I wonder if it may be time to consider 
unofficially 
retiring them using filters. 
 
 
 
 
 
 
--Jamie.Reid, CISSP, mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]Senior 
Security Specialist, Information Protection Centre Corporate Security, 
MBS  416 327 2324 >>> "Sean Donelan" 
<[EMAIL PROTECTED]> 12/03/03 05:12pm >>>You could drop 
ICMP packets at your firewall if the firewalls properlyimplemented stateful 
inspection of ICMP packets.  The problem is fewfirewalls include ICMP 
responses in their statefull analysis.  So you areleft with two bad 
choices, permit "all" ICMP packets or deny "all" 
ICMPpackets.

Re: new nasty email virus trick to bypass scanners

[Damian Gerow]

On Wed, 3 Dec 2003, Steven M. Bellovin wrote:
> Is this in the wild yet?  Any other details worth looking for?  
> Symantec's AV site apparently has nothing on it.

I would say so - I got it in my inbox earlier this afternoon, and I
traditionally get about three viruses a month.

The virus itself is *exactly* like Mmimail.M, as reported by Symantec.
Except that wendy.zip was definitely password protected.

  - Damian

Re: new nasty email virus trick to bypass scanners

[Mike Tancsa]

At 09:53 PM 03/12/2003, Jamie Reid wrote:

If an attacker can convince a user to do anything, all  bets
are off.
It is conceptually similar to  using SSL to evade a network IDS.

This is also an intrusion test trick. As system owners, there
is only so much we can do to prevent and detect compromises.
What matters is how we respond.
True enough.  However, we also have to protect naive and vulnerable users 
to some degree.  Think about elderly folk.  They are not necessarily as 
quick to spot the scam. The ability to stop the virus before it gets to 
them is important.

The other thing that worries me is that those who rely on their ISP to scan 
for viruses, a false sense of security can come into play.  In the case of 
these types of email viruses, the user might think the file is OK because 
it was scanned.

---Mike

Re: Firewall stateful handling of ICMP packets

[Steve Francis]

Jamie Reid wrote:

Personal view: 

This was a problem when filtering Nachi while it pinged networks
to their knees. 

Sometimes I wonder if there is any legitimate reason to allow 
pings from users at all 

ICMP echos are a bit of a hack and, quite literally, noise, 
and I wonder if it may be time to consider unofficially 
retiring them using filters. 
 

If every ISP rate limited icmp's on ingress (from customers and net) to 
some reasonable rate (I use 2Mbps), then you protect the net from attack 
impacts, have no impact on customers during normal times, and break 
nothing essential during times of attack (as opposed to, say, SYN rate 
limiting, which just lowers the bar for an attacker.)

Of course, this assumes that the equipment can do such policing in 
hardware, or with negligible impact...
Totally filtering ICMP echoes would raise lots of user hackles...

Re: new nasty email virus trick to bypass scanners

[Mike Tancsa]

NAI has it as well now

http://vil.nai.com/vil/content/v_100856.htm

---Mike

At 10:20 PM 03/12/2003, Damian Gerow wrote:

On Wed, 3 Dec 2003, Steven M. Bellovin wrote:
> Is this in the wild yet?  Any other details worth looking for?
> Symantec's AV site apparently has nothing on it.
I would say so - I got it in my inbox earlier this afternoon, and I
traditionally get about three viruses a month.
The virus itself is *exactly* like Mmimail.M, as reported by Symantec.
Except that wendy.zip was definitely password protected.
  - Damian

Re: Firewall stateful handling of ICMP packets

[Jeff Kell]

Jamie Reid wrote:
Personal view: 

This was a problem when filtering Nachi while it pinged networks
to their knees. 
Well, it was at least the "last straw".

Sometimes I wonder if there is any legitimate reason to allow 
pings from users at all. If the user really needed to use
ping, that is, if they were in a position to do anything about the
results of the ping tests, then they would know enough to 
use traceroute in UDP mode or some other tool. 
Personally, I like Rob Thomas (cymru) stance on ICMP filtering as given 
in http://www.cymru.com/Documents/icmp-messages.html.  This allows pings
and PMTU-relevant unreachables.  Granted there have been a few hacker 
toys that use ICMP echo-reply or other esoteric ICMP type codes to 
communicate with their "slaves", but this could be alleviated to some 
extent with "stateful" ICMP (almost an oxymoron).

The Nachi pings can be stopped by vendor C using policy routing but has 
a side effect of grabbing some unintended packets (Windows traceroute, I 
think).  If you can devise a method to see if the ICMP payload is a load 
of 0xaa's then you've narrowed it down to a science, but AFAIK vendor C 
can't do that (well, maybe an IDS appliance with a custom signature).

You can gain "some" additional protection by rate-limiting ICMP (in the 
Nachi ping case) and/or UDP (SQL Slammer, etc), and TCP intercept for 
synflooding.  Not perfect, but every little bit helps.

Jeff Kell
University of Tennessee at Chattanooga

Re: Firewall stateful handling of ICMP packets

[Adi Linden]

The problem with ICMP is that it is ICMP today. What will it be tomorrow?
It'll aways be putting out fires, controlling packet floods matching
whatever signature.

One solution is to get away from unlimited bandwidth. Once there is a cost
associated to having a PC source Nachi or Welchi traffic, customers will
learn to be more concerned and educate themselves. The cost doesn't have
to be moneytary. Progressive rate limiting could be used, where traffic
gets pinched as the allowed traffic per time slot is consumed.

Adi

Re: Firewall stateful handling of ICMP packets

[Valdis . Kletnieks]

On Wed, 03 Dec 2003 15:57:37 PST, Owen DeLong <[EMAIL PROTECTED]>  said:

> around.  (In fact, I'm hard pressed to imagine how a Frag needed packet
> for an invalid session could do much of anything).

You can use a forged 'frag needed' to stomp an existing connection of the
victim's down to 64 byte MTU or similar silliness, but other than sheer
"it's a packet" DDoS effects, I can't think of a malicious use for one for
an invalid session either


pgp0.pgp
Description: PGP signature

Re: Firewall stateful handling of ICMP packets

[Joe Abley]

On 3 Dec 2003, at 22:53, Adi Linden wrote:

One solution is to get away from unlimited bandwidth. Once there is a 
cost
associated to having a PC source Nachi or Welchi traffic, customers 
will
learn to be more concerned and educate themselves. The cost doesn't 
have
to be moneytary. Progressive rate limiting could be used, where traffic
gets pinched as the allowed traffic per time slot is consumed.
Live example of how well monetary pinching works in New Zealand -- 
there have been cases of people receiving $15,000 monthly phone bills 
which are mainly comprised of ADSL traffic charges. So, the traffic 
charges stop the rogue traffic, by sending customers bankrupt, but only 
about a month or so after the fact.

Punishing high-traffic users by progressive traffic shaping sounds more 
effective, although the implementation sounds potentially hairy.

Joe