Re: Problem of blocking ICMP packets

[Masataka Ohta]

Mark Smith;

> I'll continue reading, although I'm happy enough that my original
> understanding was correct.

Let's agree that you are as correct as PMTUD.

If you have further comments, do so offline.

Masataka Ohta



___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Problem of blocking ICMP packets

[Mark Smith]

On Tue, 11 May 2004 13:44:16 +0900
Masataka Ohta <[EMAIL PROTECTED]> wrote:

> Mark Smith;
> 
> > I'm keen to
> > find out if my understanding of PMTUD purpose and operation
> > is incorrect.
> 
> Read the RFC or my quotation of it.
> 

Ok, well, I haven't got far into it, and it seems to correspond
to what I've understood :

"2. Protocol overview

   In this memo, we describe a technique for using the Don't
Fragment   (DF) bit in the IP header to dynamically discover the
PMTU of a path.   The basic idea is that a source host initially
assumes that the PMTU   of a path is the (known) MTU of its first
hop, and sends all   datagrams on that path with the DF bit set. 
If any of the datagrams   are too large to be forwarded without
fragmentation by some router   along the path, that router will
discard them and return ICMP   Destination Unreachable messages
with a code meaning "fragmentation   needed and DF set" [7]. 
Upon receipt of such a message (henceforth   called a "Datagram
Too Big" message), the source host reduces its   assumed PMTU for
the path."

I'll continue reading, although I'm happy enough that my original
understanding was correct.


Regards,
Mark.

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Problem of blocking ICMP packets

[Masataka Ohta]

Mark Smith;

> I'm keen to
> find out if my understanding of PMTUD purpose and operation is
> incorrect.

Read the RFC or my quotation of it.

Masataka Ohta



___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Problem of blocking ICMP packets

[Mark Smith]

On Tue, 11 May 2004 03:48:57 +0900
Masataka Ohta <[EMAIL PROTECTED]> wrote:

> Mark Smith;
> 
> >>>A number of commercial
> >>>products and applications do rely on PMTU to work, and will
> >>>do an PATH MTU discovery, and send the MTU sized packets
> >with>>DF (don't frag).
> >>
> >>and send packets larger than MTU expecting to receive ICMP
> >>errors in vain.
> >>
> >>Read the original mail of the thread on the reality.
> 
> > The problem identified has nothing to do with the concept or
> > typical implementations of PMTUD being broken.
> 
> Wrong.

Ok, if you think I'm wrong, what is it that is preventing PMTUD
working, as per the RFC method of operation, in this discussion ?


> 
> > RFC1192 (http://www.rfc-editor.org/rfc/rfc1191.txt) is the
> > spec for PMTUD. 
> 
> Read the RFC.

> 
> It says "To detect increases in a path's PMTU, a host
> periodically increases its assumed PMTU".

And how does the host know that it has increased the PMTU too far
? 

I'm really interested in some references to documentation or
information that has helped you form your opinion. I'm keen to
find out if my understanding of PMTUD purpose and operation is
incorrect.

Here is a summary of the references I've cited, including an
additonal one, for further information :

(a) The RFC of course. This is the reference for PMTUD operation.

(b) Radia Perlman's book, "Interconnections", 2nd Edition. Pg
185, section 8.7. There is also some discussion of fragmentation
- related to PMTUD - on page 233, section 10.4.7

and an additional one

(c) W. Richard Stevens' book, "TCP/IP Illustrated, Volume 1".
Page 340, Section 24.2


Regards,
Mark.

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Complaint on abuse of DNSOP lists

[Noel Chiappa]

> From: Dean Anderson <[EMAIL PROTECTED]>

>> If you look at the message, you will note that it is a bounce from the
>> WG co-chair's _personal_ email address, directly to your email address.

> it was a bounce to a message Mr. Austein posted on DNSOP.

I assume you mean "it was a bounce to [a reply to] a message Mr. Austein
posted on DNSOP", right? (No need to confirm, just checking.)

> It was not private business. It was IETF business.

So? Rob's not refusing to accept *any* email *at all* from you as a person
(just from a range of addresses which are generating email he doesn't like);
and you're more than savvy enough technically to get email to him via some
other path.

He's not under any more obligation to accept email from you via whatever
channel you feel like using, no matter how onerous for him, than he is to
accept messages written on 12' long oak logs of 3' diameter.


Get a life, will you? Your constant whining and flaming is really getting
old. You're getting really close to the line at which I'd ask the Chair to
ban you from posting. Oh wait, I know what your response would be - you'd sue
us. And you seem to think the rest of the world is doing things which is
making you look bad. Here's another free clue: you're doing a far better job
of that than the rest of us could do with a decade of free time.

Noel

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Complaint on abuse of DNSOP lists

[Dean Anderson]

On Mon, 10 May 2004, John Stracke wrote:

> Dean Anderson wrote:
> 
> >It seems that WG co-chair has begun to use an email address that is 
> >defaming Av8 Internet, Inc
> >
> How is it defamation if the only one that gets the message is Av8?

Av8 customers get it.  DNSOP and IETF list members have gotten it. When I
have to republish something to make a complaint then legally it is just
like Mr. Austein published it himself. Defamation Tort Law.

--Dean


___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Complaint on abuse of DNSOP lists

[Dean Anderson]

On Mon, 10 May 2004, Ken Raeburn wrote:

> On May 10, 2004, at 14:17, Dean Anderson wrote:
> 
> > It seems that WG co-chair has begun to use an email address that is
> > defaming Av8 Internet, Inc by returning business email to users of Av8
> > Internet claiming that Av8 Internet has hijacked some address space.
> 
> That may or may not be, but since you didn't show any bounce from 
> uoregon, your claim of "abuse of DNSOP lists" in the subject line 
> appears to be unsupported.

Bounces don't have to come from Uoregon.  Mr. Austein is the WG chair.  He 
has to abide by the IETF rules, just like Uoregon (host of DNSOP)

> And I'd read the error message to suggest that perhaps Av8's net block 
> had *been* hijacked (in someone's experience, not necessarily 
> world-wide, which would be an interesting problem for globally 
> distributed block lists), not that Av8 necessarily had done it.

This isn't the case. And if it were, Av8 would make that claim, no one 
else would.

> > Av8 Internet hereby demands that the IETF immediately end this behavior
> > and halt the defamation of Av8 Internet, Inc by IETF representatives.
> > IETF representatives must use email addresses that are not configured 
> > for
> > defamation of Av8 Internet, Inc.
> 
> Yes, I'm sure that SRA was the one who submitted Av8's netblock to 
> SORBS, and set up ISC to use SORBS, as part of a secret plot to ruin 
> your reputation. 

This has no legal relevance. Repetition of defamation is still defamation. 

> How about suggesting a more positive solution, instead of throwing 
> around language like "defamation"?  Maybe, "IETF WG chairs should 
> have/use addresses that don't reject mail based on unreliable block 
> lists (for some definition of 'unreliable'), and the IETF should 
> provide a forwarding service for those chairs who cannot otherwise get 
> such an address."
> 
> I would also suggest you try to resolve the issue with SORBS, except 
> that when I tried the URL suggested, I got "ERROR: Couldn't prepare 
> statement: $dbh is (undef)".  So I guess you could question the 
> reliability of this particular service

I have been in contact with SORBS, and with ISC.ORG. SORBS Australian
operator Matthew Sullivan says "sue me, I have no assets".  I did engage
an attorney in Australia, to review the possibility of a suit, and who
confirmed that Sullivan had no visible assets. It would cost about $50k
(US) to sue, and while Australian law provides that we can recover that,
it cannot be recovered from someone who has no assets.

ISC.ORG is the US promoter of SORBS (we got it booted from other US ISPs),
but ISC.ORG doesn't want to take a complaint. Bill Manning, of EP.NET
(ISC.ORG upstream) says he has no contract with me to accept complaints
about ISC.ORG.

Fortunately, almost no one is using SORBS, or has Av8 whitelisted.  Those 
few that have used SORBS (outside of ISC.ORG) have stopped using SORBS 
when the 130.105 listing is pointed out to them.

--Dean



___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Complaint on abuse of DNSOP lists

[Dean Anderson]

On Mon, 10 May 2004, Pekka Savola wrote:

> On Mon, 10 May 2004, Dean Anderson wrote:
> > Point of order, please
> > 
> > It seems that WG co-chair has begun to use an email address that is 
> > defaming Av8 Internet, Inc by returning business email to users of Av8 
> > Internet claiming that Av8 Internet has hijacked some address space.
> > 
> > Av8 Internet hereby demands that the IETF immediately end this behavior
> > and halt the defamation of Av8 Internet, Inc by IETF representatives.  
> > IETF representatives must use email addresses that are not configured for
> > defamation of Av8 Internet, Inc.
> 
> If you look at the message, you will note that it is a bounce from the
> WG co-chair's _personal_ email address, directly to your email
> address.

Actually, it bounces this way to all Av8 Internet Customers, not just to
me.  But it was a bounce to a message Mr. Austein posted on DNSOP. It was
not private business. It was IETF business.

Further, by reviewing the archives of DNSOP, I have found that Mr.  
Austein's home address is <[EMAIL PROTECTED]>, which he has used
exclusively for some time until March 1st of this year. He first started
using the ISC.ORG address on a message involving
draft-ietf-dnsop-inadr-required. Perhaps coincidentally, this draft is a
pet project of Mr. Austeins, and one to which I (and many others) have
raised serious objections regarding both misleading and incorrect content
and procedural irregularities.  The archives show that since March 1st,
2004, Mr.  Austein has made all his DNSOP posts from [EMAIL PROTECTED]  

> I'd say that everyone has the right to choose what mail to accept (or
> not to accept).

They don't when they are conducting IETF business. IETF rules require that
participants not be excluded from IETF activities. WG chairs and others
cannot refuse email from participants.

As Joe Abley revealed previously, this configuration from ISC.ORG isn't
meant to actually block spam. The idea is to make Av8 Internet users have
to seek other email addresses by which to contact them, and to obtain
opportunities to defame Av8 Internet and perhaps others and convince users
to seek other services. This is unlawful.  Besides the defamation, it
would is an illegal group boycott, and an unfair business practice.

Refusing email is one thing, though that is still not permitted for IETF
business.  Defamation by claiming addresses are hijacked is quite another
thing. This abuse of email addresses is unacceptable, and illegal, and I
can engage legal action if necessary to prevent an organization like the
IETF from permitting this abuse to continue.

Mr. Austein cannot be allowed to use the ISC.ORG address for IETF
business.

> You might or might not have a point if this behaviour happened on an 
> IETF list, but that is not the case..

Actually, it is the case. This involves two IETF lists, and the conduct of
an IETF representative on the DNSOP list. My republishing of Mr. Austein's
defamation to the DNSOP and IETF list to make a complaint is a
republishment for which Mr.  Austein and the IETF are legally responsible
under US defamation tort law.

Mr Austein as a representative of the IETF defamed Av8 Internet to me, to
the customers of Av8 Internet, and to the readership of both the IETF and
DNSOP lists.  Mr. Austein is a co-chair of the IETF working group.  This
defamation came about through IETF working group business.

The IETF is responsible for the conduct of its representatives on its
lists.  It is unlawful to permit its representatives to use addresses
which are configured to defame IETF participants, and it is against the
IETF rules to refuse email from IETF participants.

Dean Anderson
President
Av8 Internet, Inc













___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Problem of blocking ICMP packets

[Anthony DeRobertis]

On May 10, 2004, at 15:25, Masataka Ohta wrote:

Sensible people should block PMTUD, too.
Why? Do you just enjoy breaking random things?



___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Complaint on abuse of DNSOP lists

[John Stracke]

Dean Anderson wrote:

It seems that WG co-chair has begun to use an email address that is 
defaming Av8 Internet, Inc

How is it defamation if the only one that gets the message is Av8?

--
/===\
|John Stracke  |[EMAIL PROTECTED]|
|Principal Engineer|http://www.centive.com  |
|Centive   |My opinions are my own. |
|===|
|I'm not a bibliophile, I'm a bibliophiliac. Put me in a|
|bookstore, & my wallet bleeds. |
\===/
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Problem of blocking ICMP packets

[Masataka Ohta]

Dean Anderson;

>>There were (still are?) number of web servers that wanted to send
>>big packets with DF turned on, because PMTUD was turned on on the
>>servers but ICMP errors were filtered.

> There still are such apps.  I ran into this recently, last winter.

So, that is the reality. Note that we run into this only if
there are both such servers and such filters.

> The
> network can't possibly work if people are going to turn
> critical parts of it off, parts that they don't fully understand.

The most critical ICMP generated by intermediate routers is
TTL exceeded, I think, though it is not critical for real
applications.

We can do without others. However, there are people who want to
invent inappropriate use of inessential features. For example,
TCP should not be disconnected upon network unreachable ICMP but
some TCP did. PMTUD is, IMHO, another example.

> I think we disagree on the "reality". The reality is that most sensible
> people and ISPs don't block harmless ICMP messages.

Sensible people should block PMTUD, too.

>>>This is the first I have heard that path mtu discovery software was
>>>unreliable.

>>Can you tell me who said it with an appropriate reference?

> Err, _you_ said it:

I never said software unreliable.

Note that an example of unreliable software is Windows.

Masataka Ohta


___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Complaint on abuse of DNSOP lists

[Ken Raeburn]

On May 10, 2004, at 14:17, Dean Anderson wrote:

It seems that WG co-chair has begun to use an email address that is
defaming Av8 Internet, Inc by returning business email to users of Av8
Internet claiming that Av8 Internet has hijacked some address space.
That may or may not be, but since you didn't show any bounce from 
uoregon, your claim of "abuse of DNSOP lists" in the subject line 
appears to be unsupported.

And I'd read the error message to suggest that perhaps Av8's net block 
had *been* hijacked (in someone's experience, not necessarily 
world-wide, which would be an interesting problem for globally 
distributed block lists), not that Av8 necessarily had done it.

Av8 Internet hereby demands that the IETF immediately end this behavior
and halt the defamation of Av8 Internet, Inc by IETF representatives.
IETF representatives must use email addresses that are not configured 
for
defamation of Av8 Internet, Inc.
Yes, I'm sure that SRA was the one who submitted Av8's netblock to 
SORBS, and set up ISC to use SORBS, as part of a secret plot to ruin 
your reputation. 

How about suggesting a more positive solution, instead of throwing 
around language like "defamation"?  Maybe, "IETF WG chairs should 
have/use addresses that don't reject mail based on unreliable block 
lists (for some definition of 'unreliable'), and the IETF should 
provide a forwarding service for those chairs who cannot otherwise get 
such an address."

I would also suggest you try to resolve the issue with SORBS, except 
that when I tried the URL suggested, I got "ERROR: Couldn't prepare 
statement: $dbh is (undef)".  So I guess you could question the 
reliability of this particular service

Ken

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Complaint on abuse of DNSOP lists

[Pekka Savola]

On Mon, 10 May 2004, Dean Anderson wrote:
> Point of order, please
> 
> It seems that WG co-chair has begun to use an email address that is 
> defaming Av8 Internet, Inc by returning business email to users of Av8 
> Internet claiming that Av8 Internet has hijacked some address space.
> 
> Av8 Internet hereby demands that the IETF immediately end this behavior
> and halt the defamation of Av8 Internet, Inc by IETF representatives.  
> IETF representatives must use email addresses that are not configured for
> defamation of Av8 Internet, Inc.

If you look at the message, you will note that it is a bounce from the
WG co-chair's _personal_ email address, directly to your email
address.

I'd say that everyone has the right to choose what mail to accept (or
not to accept).

You might or might not have a point if this behaviour happened on an 
IETF list, but that is not the case..

> -- Forwarded message --
> Date: Sun, 9 May 2004 20:17:23 -0400
> From: Mail Delivery Subsystem <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Returned mail: see transcript for details
> 
> The original message was received at Sun, 9 May 2004 20:17:14 -0400
> from cirrus.av8.net [130.105.36.66]
> 
>- The following addresses had permanent fatal errors -
> <[EMAIL PROTECTED]>
> (reason: 553 Service unavailable; Client host [130.105.36.66] blocked using 
> dnsbl.sorbs.net; Hijacked/Disused Netblock See: 
> http://www.dnsbl.sorbs.net/cgi-bin/lookup?IP=130.105.36.66)
> 
>- Transcript of session follows -
> ... while talking to mx-1.isc.org.:
> >>> DATA
> <<< 553 Service unavailable; Client host [130.105.36.66] blocked using 
> dnsbl.sorbs.net; Hijacked/Disused Netblock See: 
> http://www.dnsbl.sorbs.net/cgi-bin/lookup?IP=130.105.36.66
> 550 5.1.1 <[EMAIL PROTECTED]>... User unknown
> <<< 554 Error: no valid recipients
> 

-- 
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Problem of blocking ICMP packets

[Masataka Ohta]

Mark Smith;

>>>A number of commercial
>>>products and applications do rely on PMTU to work, and will
>>>do an PATH MTU discovery, and send the MTU sized packets with
>>>DF (don't frag).
>>
>>and send packets larger than MTU expecting to receive ICMP
>>errors in vain.
>>
>>Read the original mail of the thread on the reality.

> The problem identified has nothing to do with the concept or
> typical implementations of PMTUD being broken.

Wrong.

> RFC1192 (http://www.rfc-editor.org/rfc/rfc1191.txt) is the spec
> for PMTUD. 

Read the RFC.

It says "To detect increases in a path's PMTU, a host periodically
increases its assumed PMTU".

Masataka Ohta



___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Not sure if this is the right place for this

[Anthony DeRobertis]

On May 10, 2004, at 10:38, Eric A. Hall wrote:

Using an encrypted port just means an attack can only produce failure,
rather than inducing fallback.
Clients generally default to using the unencrypted port.

Clients generally default to accepting non-STARTTLS connections.

Both require configuration changes to be fully secure. At least with 
starttls you are secure against a passive attacker (because clients use 
starttls if they can).

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Complaint on abuse of DNSOP lists

[Dean Anderson]

Point of order, please

It seems that WG co-chair has begun to use an email address that is 
defaming Av8 Internet, Inc by returning business email to users of Av8 
Internet claiming that Av8 Internet has hijacked some address space.

Av8 Internet hereby demands that the IETF immediately end this behavior
and halt the defamation of Av8 Internet, Inc by IETF representatives.  
IETF representatives must use email addresses that are not configured for
defamation of Av8 Internet, Inc.

Dean Anderson
Av8 Internet, Inc



-- Forwarded message --
Date: Sun, 9 May 2004 20:17:23 -0400
From: Mail Delivery Subsystem <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Returned mail: see transcript for details

The original message was received at Sun, 9 May 2004 20:17:14 -0400
from cirrus.av8.net [130.105.36.66]

   - The following addresses had permanent fatal errors -
<[EMAIL PROTECTED]>
(reason: 553 Service unavailable; Client host [130.105.36.66] blocked using 
dnsbl.sorbs.net; Hijacked/Disused Netblock See: 
http://www.dnsbl.sorbs.net/cgi-bin/lookup?IP=130.105.36.66)

   - Transcript of session follows -
... while talking to mx-1.isc.org.:
>>> DATA
<<< 553 Service unavailable; Client host [130.105.36.66] blocked using 
dnsbl.sorbs.net; Hijacked/Disused Netblock See: 
http://www.dnsbl.sorbs.net/cgi-bin/lookup?IP=130.105.36.66
550 5.1.1 <[EMAIL PROTECTED]>... User unknown
<<< 554 Error: no valid recipients
Reporting-MTA: dns; cirrus.av8.net
Received-From-MTA: DNS; cirrus.av8.net
Arrival-Date: Sun, 9 May 2004 20:17:14 -0400

Final-Recipient: RFC822; [EMAIL PROTECTED]
Action: failed
Status: 5.1.3
Remote-MTA: DNS; mx-1.isc.org
Diagnostic-Code: SMTP; 553 Service unavailable; Client host [130.105.36.66] blocked using dnsbl.sorbs.net; Hijacked/Disused Netblock See: http://www.dnsbl.sorbs.net/cgi-bin/lookup?IP=130.105.36.66
Last-Attempt-Date: Sun, 9 May 2004 20:17:20 -0400
--- Begin Message ---
I think it is a good idea too, but I don't see why it needs an RFC.  It is
purely administrative function in a nameserver to configure it not go give
out certain data to requests from, say, certain IP ranges. The issues of
'how it works' and what features, administrative syntax, etc seem to me to
be as proprietary as the server configuration file.

Indeed, it should be easy for some nameservers (powerDNS comes to mind)  
to do this now.  But it doesn't change the protocol, it just changes the
administration and operation of the server.


--Dean

On Fri, 7 May 2004, Rob Austein wrote:

> At Thu, 06 May 2004 17:26:34 +0900, Jun-ichiro itojun Hagino wrote:
> > 
> > could you tell me what happened to
> > draft-ietf-dnsop-dontpublish-unreachable-03.txt?  it has been expired
> > for some time now.  i think it is a good document...
> 
> I thought it was useful too.  If I recall the history of this one
> correctly, it was a WG document which a number of people liked, but
> the WG ratholed discussing how many angels can dance on the word
> "unreachable", why firewalls are an offense before God, Man, and Small
> Furry Creature From Alpha Centauri, and other nonterminating topics.
> The author, not being totally out of his mind, eventually found
> something more productive to do with his time.
> 
> This document is not on the WG's current charter, because the last
> time we asked for a volunteer, the silence was deafening.  Absent
> somebody willing to work on it, there is no point in asking our ADs to
> let us put it back on the charter.
> 
> So: who cares about bringing this one back enough to work on it?
> 
> Given what happened the last time that I foolishly asserted from
> memory that an author had given up on a DNSOP WG doc, let me phrase
> this as a two part question:
> 
> a) Is the author interested in bringing back this document?  If so, he
>of course has dibs.
> 
> b) Otherwise, is there somebody else who would be interested in
>picking up the pen?
> .
> dnsop resources:_
> web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
> mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
> 

--- End Message ---

Re: Problem of blocking ICMP packets

[Anthony DeRobertis]

On May 9, 2004, at 19:33, Dean Anderson wrote:
I have only heard that those that block ICMP echo have had
problems.
Nothing to do with ICMP echo. It's blocking ICMP unreachable, 
fragmentation needed that causes problems.

ICMP unreachables related to known connections should be allowed 
through the firewall.

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Problem of blocking ICMP packets

[Dean Anderson]

On Mon, 10 May 2004, Masataka Ohta wrote:

> Dean Anderson;
> 
> >>I recommend that, to avoid long initial delay and intermediate
> >>lack of communication after path changes of, PMTUD should turnd
> >>off by default and should be activated only on extreme
> >>conditions.
> 
> > Just the opposite, unless you want to lose connectivity with a number of 
> > web servers that want to send big packets with DF turned on.
> 
> There were (still are?) number of web servers that wanted to send
> big packets with DF turned on, because PMTUD was turned on on the
> servers but ICMP errors were filtered.

There still are such apps.  I ran into this recently, last winter.

I'd suggest those complaining should get a few more clues about what ICMP
does, and stop filtering ICMP packets that aren't threatening.  The
network can't possibly work if people are going to turn critical parts of
it off, parts that they don't fully understand.  There is no surprise that
they have problems. This isn't a reason to change the network. There are
other things that they don't understand, and could turn off.  One can't
remove all switches and levers.

> > A number of commercial
> > products and applications do rely on PMTU to work, and will do an PATH MTU 
> > discovery, and send the MTU sized packets with DF (don't frag).
> 
> and send packets larger than MTU expecting to receive ICMP
> errors in vain.
> 
> Read the original mail of the thread on the reality.

I think we disagree on the "reality". The reality is that most sensible
people and ISPs don't block harmless ICMP messages. Of course, not _all_
ICMP messages from anywhere are harmless, but that doesn't mean that all
such messages are all harmful.  Blocking everything is a club-footed
method of security, if you'll pardon the pun.

Those that pick such an approach cannot be accomodated, because they're
clubfooted, as it were---if it isn't this, its something else.  
Cluelessly turning things off will have a bad effect on any system. Case
in point: It seems that something similar (in principle anyway) was what
caused the Three Mile Island Nuclear Plant to melt down: The operators
turned off the emergency cooling system pumps wrongly. It took an engineer
to tell them to turn them back on, but by then it was too late to prevent
damage.  People have suggested that the switch to turn off the pumps
should be removed from all nuclear plants. This is also wrong. There might
be a need to do that someday.

The solution is to better train the operators, so that they don't mess
with things they don't fully understand.  This is just as true of
networks, as it is of nuclear power plants. Probably more so of networks,
since these sorts of things happen more frequently, and even the network
engineers aren't nearly as uniformly trained, much less so the operators.

> > This is the first I have heard that path mtu discovery software was
> > unreliable.
> 
> PMTUD software is unreliable!?
> 
> Then, it is anther reason to avoid it.
> 
> Can you tell me who said it with an appropriate reference?

Err, _you_ said it:

On Sat, 8 May 2004, Masataka Ohta wrote:
> Further, it should be noted that PMTUD is so unreliable that
> no applications rely on it, which means that even under
> extreme conditions rational operators won't turn on PMTUD.
>
> In short, forget PMTUD.
>   Masataka Ohta
>
>




___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Not sure if this is the right place for this

[John Stracke]

John Rudd wrote:

The problem with the STARTTLS strategy is: you can't guarantee at the 
network level that a client will use SSL/TLS.
Guaranteeing that the client will use TLS is worthless anyway, since TLS 
includes the "None" encryption option.

--
/==\
|John Stracke  |[EMAIL PROTECTED]   |
|Principal Engineer|http://www.centive.com |
|Centive   |My opinions are my own.|
|==|
|Guide us, oh holy Lemming Herder! |
\==/
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Not sure if this is the right place for this

[Paul Hoffman / VPNC]

At 9:38 AM -0500 5/10/04, Eric A. Hall wrote:
On 5/10/2004 3:02 AM, RL 'Bob' Morgan wrote:

 So a "secure ports only" policy has very little to do with security and
 very much to do with organizational power relationships, and making
 your computing environment dysfunctional.
Somebody check my math on this please, but it seems to me that the whole
STARTTLS approach is succeptible to a specific attack which the secure
socket model is not.
Specifically, a man-in-the-middle can "blank out" the STARTTLS feature
advertisement, and thus make the client believe that TLS is not available.
For example:
  server-AMitM  client-C
 |  250-DSN | 250-DSN
 +-->   250-AUTH+->   250-AUTH
250-STARTTLS  250 ok [...pad...]
250 ok
The client, seeing that TLS is not available, dumbs down to cleartext.
Most clients would probably do that invisibly without even barking at the
user, or not doing so in a way that most of them would appreciate.
Using an encrypted port just means an attack can only produce failure,
rather than inducing fallback.
Unless that's wrong for some reason, I'd say that a "secure ports policy"
actually is more secure.
In many cases, a client for a "secure ports policy" protocol will 
fall back to the insecure port instead of telling the user "you can't 
communicate". That's not true for HTTPS, but it is true for secure 
POP, secure SMTP, and so on.

A man-in-the-middle can more easily block the secure port than he/she 
can elide the STARTTLS messing in the client's start-up. STARTTLS is 
harder to mount than blocking a "secure port". Thus, the "secure 
ports policy" makes the MITM's job easier.

BTW, sometimes the MITM in the "secure ports only" scenario is a 
clueless firewall admin at any point in the transit. The STARTTLS 
method is not susceptible to this unintentional-but-still-deadly 
downgrade attack.

Any client that is willing to back down to non-secure mode is 
susceptible to a MITM attack, regardless of the protocol.

--Paul Hoffman, Director
--VPN Consortium
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'The IESG and RFC Editor documents: Procedures' to BCP

[Pete Resnick]

On 5/10/04 at 10:54 AM -0400, John C Klensin wrote:

--On Monday, May 10, 2004 9:33 AM -0400 Scott Bradner <[EMAIL PROTECTED]> wrote:

looks good to me - one suggestion of clearer language and a
potential addition
  o  Documents for which special rules exist, including IAB 
documents and April 1st RFCs, and republication of documents from 
other SDOs - the IESG and the RFC Editor keep a running dialogue 
on which documents these are
awkward wording - maybe you want to say

   o  The IESG and the RFC Editor keep a running dialogue on which 
documents require special rules (for example, IAB documents, April 
1st RFCs, and republication of documents from other SDOs)
Scott, while I agree that the current language is not optimal, I 
don't think the above is the right fix.   The whole point of the 
agreements about publication of IAB documents is that the RFC Editor 
reports, from an overall policy and strategy standpoint, with the 
IAB.  Turning that situation into "the IESG and the RFC Editor keep 
a running dialogue" rather dramatically revises (or confuses) that 
situation.
John, the paragraph which Scott aims to fix is in the section which 
describes "what is currently happening". And, indeed, I believe it is 
true that the current state of affairs is that the IESG and the RFC 
Editor *do* keep a running dialogue about out-of-the-ordinary 
documents which may or may not need IESG review (where republication 
of certain SDO documents do -- because of liaison agreements -- and 
April 1st RFCs do not, as far as I know).

Perhaps this would be better stated as:

o  The IESG and the RFC Editor keep a running dialogue on which 
documents require special rules (for example, IAB informational 
documents and April 1st RFCs never require IESG review, whereas 
certain republication of documents from other SDOs do because of 
liaison agreements)

(assuming that captures what Harald, and Scott, intended in their attempts).
--
Pete Resnick 
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'The IESG and RFC Editor documents: Procedures' to BCP

[Scott Bradner]

fwiw - this works for me

---
From: John C Klensin <[EMAIL PROTECTED]>
To: Scott Bradner <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Last Call: 'The IESG and RFC Editor documents:
 Procedures' to BCP

--On Monday, May 10, 2004 10:57 AM -0400 Scott Bradner 
<[EMAIL PROTECTED]> wrote:

> note that I just used the words that were there - do you
> suggest  leaving teh words as they are?  if not, maybe you can
> suggest something better

I guess that, before, the text was sufficiently muddy that I 
didn't catch the real problem, so thanks for trying to clarify 
it :-(.

Perhaps it should say something like...

  o  Special rules exist for some documents, including
IAB
documents and April 1st RFCs, and republication of
documents from other SDOs.  In some cases, these rules
exist because the RFC Editor reports to the IAB on
policy and strategy matters.  The IESG and the RFC
Editor keep a running dialogue, in consultation with the
IAB, on other documents and classification of them.

I think that represents the current situation and agreements, 
and assume that the other text was just confusing.   As you 
know, quite a lot of anguish has gone into this topic area in 
the past. It would be, IMO, a mistake to even reopen the issue 
unless there is compelling need to do so.

 john


___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'The IESG and RFC Editor documents: Procedures' to BCP

[John C Klensin]

--On Monday, May 10, 2004 10:57 AM -0400 Scott Bradner 
<[EMAIL PROTECTED]> wrote:

note that I just used the words that were there - do you
suggest  leaving teh words as they are?  if not, maybe you can
suggest something better
I guess that, before, the text was sufficiently muddy that I 
didn't catch the real problem, so thanks for trying to clarify 
it :-(.

Perhaps it should say something like...

  o  Special rules exist for some documents, including
IAB
documents and April 1st RFCs, and republication of
documents from other SDOs.  In some cases, these rules
exist because the RFC Editor reports to the IAB on
policy and strategy matters.  The IESG and the RFC
Editor keep a running dialogue, in consultation with the
IAB, on other documents and classification of them.
I think that represents the current situation and agreements, 
and assume that the other text was just confusing.   As you 
know, quite a lot of anguish has gone into this topic area in 
the past. It would be, IMO, a mistake to even reopen the issue 
unless there is compelling need to do so.

john

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'The IESG and RFC Editor documents: Procedures' to BCP

[John C Klensin]

--On Monday, May 10, 2004 9:33 AM -0400 Scott Bradner 
<[EMAIL PROTECTED]> wrote:

looks good to me - one suggestion of clearer language and a
potential addition
  o  Documents for which special rules exist, including IAB
  documents and April 1st RFCs, and republication of
 documents from other SDOs - the IESG and the RFC Editor
 keep a running dialogue on which documents these are
awkward wording - maybe you want to say

   o  The IESG and the RFC Editor keep a running dialogue on
which documents require special rules (for example,
IAB documents, April 1st RFCs, and republication of
documents from other SDOs)
Scott, while I agree that the current language is not optimal, I 
don't think the above is the right fix.   The whole point of the 
agreements about publication of IAB documents is that the RFC 
Editor reports, from an overall policy and strategy standpoint, 
with the IAB.  Turning that situation into "the IESG and the RFC 
Editor keep a running dialogue" rather dramatically revises (or 
confuses) that situation.

   john

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Not sure if this is the right place for this

[Eric A. Hall]

On 5/10/2004 3:02 AM, RL 'Bob' Morgan wrote:

> So a "secure ports only" policy has very little to do with security and
> very much to do with organizational power relationships, and making
> your computing environment dysfunctional.

Somebody check my math on this please, but it seems to me that the whole
STARTTLS approach is succeptible to a specific attack which the secure
socket model is not.

Specifically, a man-in-the-middle can "blank out" the STARTTLS feature
advertisement, and thus make the client believe that TLS is not available.
For example:

  server-AMitM  client-C
 |  250-DSN | 250-DSN
 +-->   250-AUTH+->   250-AUTH
250-STARTTLS  250 ok [...pad...]
250 ok

The client, seeing that TLS is not available, dumbs down to cleartext.
Most clients would probably do that invisibly without even barking at the
user, or not doing so in a way that most of them would appreciate.

Using an encrypted port just means an attack can only produce failure,
rather than inducing fallback.

Unless that's wrong for some reason, I'd say that a "secure ports policy"
actually is more secure.


___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'The IESG and RFC Editor documents: Procedures' to BCP

[Scott Bradner]

looks good to me - one suggestion of clearer language and a potential
addition

>   o  Documents for which special rules exist, including IAB documents
>  and April 1st RFCs, and republication of documents from other SDOs
>  - the IESG and the RFC Editor keep a running dialogue on which
>  documents these are

awkward wording - maybe you want to say

   o  The IESG and the RFC Editor keep a running dialogue on which
documents require special rules (for example, IAB documents,
April 1st RFCs, and republication of documents from other SDOs)

section 3
>The IESG may return five different responses

this misses one of the outcomes listed in RFC 2026 - specifically (quoting
from 2026):
"the IESG recommends that the document be brought within the
IETF and progressed within the IETF context"

this path has been used from time to time and I think it is a valuable
option - I'd suggest that it be added as a 6th response

Scott

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Not sure if this is the right place for this

[RL 'Bob' Morgan]

John:

There is actually a list for discussion of this topic,
[EMAIL PROTECTED], though it hasn't seen much traffic for quite a
while.

Your note is a reminder that this issue, while much-debated on the various
apps-protocol lists a few years ago when the decisions to invent and
promote STARTTLS were made, is not well-described (so far as I know) in
any RFC.  An informational (or maybe BCP) RFC presenting the reasons why
the separate-port approach is a poor choice, and promoting some good
practices for clients and servers using STARTTLS, would be a good thing
(he said, not quite volunteering).

In a nutshell, the reason STARTTLS is a better approach is that, rather
than treating the use of SSL/TLS as entirely different than other session
characteristics, it permits the use of TLS to be negotiated by client and
server, just as other protocol features are negotiated.  The most
important practical benefit of this is that clients can be designed with
their default behavior to try STARTTLS (perhaps based on a server's
announcing it as a capability), thus giving the generic user the benefits
of TLS-protected connections without having to configure anything.  With
the separate-port approach, the user (in any client I have ever seen) has
to configure the use of the separate port, which in many deployment
scenarios means it doesn't get used at all (since every required obscure
user config step is another $NN of support cost).  (There are lots of
other reasons I won't go into now since I'm up too late already.)

Promoting long-term the use of both STARTTLS and separate ports is also a
bad thing, since having two ways to do the same thing is guaranteed to be
confusing, and security stuff is already confusing enough.
Unfortunately, the separate-port meme has been drilled into people's heads
very effectively by http/https, so it's likely that clients will support
it for a long time to come, but there is no way that this will be anything
other than legacy-compatibility behavior (ie, it won't be specified in
standards RFCs).

Your network administrators are well-meaning, I'm sure, but their policy
is just foolish.  They might reflect on the fact that there are lots of
non-TLS ways to avoid reusable-passwords-in-the-clear with common app
implementations (on the plain old port), including Kerberos, CRAM-MD5,
DIGEST, SRP, and others.  They might reflect on the fact that filtering
out ports just makes people send their traffic over the ports that remain
open, which almost universally includes port 80.  So a "secure ports only"
policy has very little to do with security and very much to do with
organizational power relationships, and making your computing environment
dysfunctional.  Try a "secure servers only" initiative.  It worked much
better for us at my university.

 - RL "Bob"


___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Problem of blocking ICMP packets

[Matt Mathis]

On Sun, 9 May 2004, Masataka Ohta wrote:
> Back to the original problem, PMTUD depends on the capabilities
> of intermediate systems on a path to generate certain ICMP,
> generation of which is as complex as fragmentation itself,
> that it is not very end to end.
> 
> That is, PMTUD is a broken concept.

This is the whole point of reopening the original pmtud working group.
http://www.ietf.org/html.charters/pmtud-charter.html

See draft-ietf-pmtud-method-01.txt   I quote:

   This document describes a robust new method for Path MTU Discovery
   that relies on TCP or other Packetization Layer to probe an Internet
   path with progressively larger packets.  This method is described as
   an extension to RFC 1191 and RFC 1981.
   ...
   The general strategy of the new algorithm is to start with a small
   MTU and probe upward, testing successively larger MTUs by probing
   with single packets.  If the probe is successfully delivered, then
   the MTU is raised.  If the probe is lost, it is treated as an MTU
   limitation and not as a congestion signal.


This does not require any messages from the network, and works just fine with 
arbitrary middleboxes that either toss over-sized frames or ICMP 
messages.

Comments, suggestions and additions to the text are welcome.  The document is 
not well baked, but there is running code.   There is some (slightly out of 
date) background info at http://www.psc.edu/~mathis/MTU/#pmtud

Thanks,
--MM--
---
Matt Mathis  http://www.psc.edu/~mathis
Work:412.268.3319Home/Cell:412.654.7529
---


___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf