Re: Smallest Transit MTU

[John Kristoff]

On Fri, 31 Dec 2004 01:51:01 -0500
"Robert E.Seastrom" <[EMAIL PROTECTED]> wrote:

> You must not remember how SunOS 4 responded when handed icmp echo
> requests with the record-route option set (passed the packet on for
> the next guy to enjoy and then promptly paniced).
[...]

Now I know wide deployment of IPv6 is in jeopardy.  If using 2 reserved
bits in a TCP header causes this kind of fear, imagine the resistance
IPv6 and it's redefinition of 20 bytes plus an addition of 20 has yet to
see.

John

Re: Smallest Transit MTU

[Robert E . Seastrom]

John Kristoff <[EMAIL PROTECTED]> writes:

> I think you may be fearful that the use of reserved bits introduces
> a new security risk, because of something a system may do in response
> to the use of those new fields.  That is a very legitimate concern
> and a very real potential risk.  I guess in my view of the world, in
> practical terms, we're not likely to see an experimental protocol
> start getting widely deployed and then suddenly discover that we have
> a major security threat on our hands that we cannot easily fix before
> it brings the net to a complete halt.  At least not since the
> publication of RFC 793.  :-)

You must not remember how SunOS 4 responded when handed icmp echo
requests with the record-route option set (passed the packet on for
the next guy to enjoy and then promptly paniced).

A deny-all-permit-some firewall that passes through IP options which
are not explicitly needed for the operation of some specific end-node
would qualify for the "unclear on the concept" award.

---Rob

Re: Smallest Transit MTU

[J. Oquendo]

On Fri, 31 Dec 2004 [EMAIL PROTECTED] wrote:

>
> And where, exactly, do you draw the line between "firewall that blocks
> unknown bits" and "virus-scanning front-end appliance that blocks unknown
> MIME types" and "Great Firewall" that blocks all traffic that contains
> subversive content.
>

Personally I think the line should be drawn between the HIDS that rest
after the NIDS appliance after the load balancer that falls in the ECM of
Cisco's SAFE Campus Infrastructure Module that conforms to RFC's 12692
and RFC's 31337.

Happy Nother Year!


=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
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

"How a man plays the game shows something of his
character - how he loses shows all" - Mr. Luckey

Re: Smallest Transit MTU

[Valdis . Kletnieks]

On Thu, 30 Dec 2004 22:09:05 PST, David Schwartz said:
> 
> 
> > David Schwartz:
> 
> > >   IMO, it's negligent to configure a firewall to pass
> > > traffic whose meaning is not known.
> 
> > I see. Can you suggest a firewall that supports "block all traffic not
> > unencrypted and in American English"?
> 
>   You misunderstand what I mean by "whose meaning is not known".
> Deliberately, I suspect.

He *does* have a point - the fact that the firewall knows about the new
feature doesn't mean that the target host behind the firewall is able to
do something reasonable/correct with the new feature

And where, exactly, do you draw the line between "firewall that blocks
unknown bits" and "virus-scanning front-end appliance that blocks unknown
MIME types" and "Great Firewall" that blocks all traffic that contains
subversive content.


pgpCMqHSLVZD1.pgp
Description: PGP signature

RE: Smallest Transit MTU

[David Schwartz]

> David Schwartz:

> > IMO, it's negligent to configure a firewall to pass
> > traffic whose meaning is not known.

> I see. Can you suggest a firewall that supports "block all traffic not
> unencrypted and in American English"?

You misunderstand what I mean by "whose meaning is not known".
Deliberately, I suspect.

DS

RE: Smallest Transit MTU

[Matthew Kaufman]

David Schwartz:
>   IMO, it's negligent to configure a firewall to pass 
> traffic whose meaning is not known. 

I see. Can you suggest a firewall that supports "block all traffic not
unencrypted and in American English"?

That'd probably stop the kids who insist on substituting numbers for
letters, at the very least.

Matthew Kaufman
[EMAIL PROTECTED]

Ps. For my overseas deployments, I'll need some other languages supported as
well.

RE: Smallest Transit MTU

[Scott Weeks]

:   I, for one, do not agree. End hosts and firewalls *should* reject all
: traffic they don't understand. It's precisely to prevent our unintentional

It depends on weather you're a site or transit provider.  If you're a
site, you can do this.  If you're transit, that's what you get paid for.
To transport all packets.  Old argument.  See the archives.

scott

RE: Smallest Transit MTU

[David Schwartz]

> On Thu, 30 Dec 2004 17:42:44 -0800
> "David Schwartz" <[EMAIL PROTECTED]> wrote:

> I think you may be fearful that the use of reserved bits introduces
> a new security risk, because of something a system may do in response
> to the use of those new fields.  That is a very legitimate concern
> and a very real potential risk.  I guess in my view of the world, in
> practical terms, we're not likely to see an experimental protocol
> start getting widely deployed and then suddenly discover that we have
> a major security threat on our hands that we cannot easily fix before
> it brings the net to a complete halt.  At least not since the
> publication of RFC 793.  :-)

The point is one of when you make the decision to allow the new 
protocol.
Your opinion is, though I'm sure you wouldn't put it this way, before you
even know anything about it. My opinion is that it should be made when you
have enough information to know whether you want to allow it or not.

We might be able to agree that those who need the additional level of
security of blocking unknown, reserved bits should also be able to supply
the additional level of cluefulness to maintain that configuration. And I
might be willing to admit that commodity firewalls should not assume
operational cluefulness by default.

> I think the concept of reserved fields is a relatively well accepted
> practice in computing by now.  Security is important, but we cannot
> allow security concerns to completely halt progress.  It just may be
> in the interest of security to allow this kind of experimentation to
> occur.

Sure, as a considered decision made on a case by case basis, at least 
for
those clueful enough to make such a decision and concerned enough to attempt
to do so.

> > IMO, it's negligent to configure a firewall to pass traffic
> > whose meaning is not known.

> That means no end host to end host encryption that the network
> firewall cannot understand.

This might be allowed on a case-by-case basis. But it definitely should 
not
be allowed by default except for specific cases where it's decided that the
benefits outweigh the risks.

> ...and for anyone else who likes to block unknown bits, then don't
> let me see or hear you complain about how the net sucks, because you
> are not letting it evolve so that it can be fixed.  :-)

Of course you have no right to complain if traffic you chose to block
causes you to be unable to interoperate. And you do have a right to complain
if your vendor's default firewall configuration forces you to have a higher
level of cluefulness than a more sensible default configuration might have
required.

The insoluble (I fear) problem is simply that people don't maintain 
their
filters. And auto-updating your filters on someone else's say so isn't a
reasonable solution. People often won't update if they don't personally see
the problem, and you don't usually see the traffic you don't get and don't
understand.

DS

Re: Smallest Transit MTU

[John Kristoff]

On Thu, 30 Dec 2004 17:42:44 -0800
"David Schwartz" <[EMAIL PROTECTED]> wrote:

>   I, for one, do not agree. End hosts and firewalls *should* reject
> all traffic they don't understand. It's precisely to prevent our
> unintentional participation (as end hosts) in such 'experiments' that
> we deploy such filters. The problem is when the policies are not
> maintained (or are
[...]

If everyone actually did that, it would make upgrades to lots of
things very interesting.  We'd have to rely on the initial design
and implementation being close to or at perfection for now and
long into the future.

If you do not upgrade or configure your systems to understand the new
use of previously reserved bits then in the typical case you would
silently ignore those bits and things would just continue to work in
the way you were used to.  Most people designing ways to make use of
reserved bits in Internet protocols these days I think understand
backwards compatibility is often a requirement.

I think you may be fearful that the use of reserved bits introduces
a new security risk, because of something a system may do in response
to the use of those new fields.  That is a very legitimate concern
and a very real potential risk.  I guess in my view of the world, in
practical terms, we're not likely to see an experimental protocol
start getting widely deployed and then suddenly discover that we have
a major security threat on our hands that we cannot easily fix before
it brings the net to a complete halt.  At least not since the
publication of RFC 793.  :-)

I think the concept of reserved fields is a relatively well accepted
practice in computing by now.  Security is important, but we cannot
allow security concerns to completely halt progress.  It just may be
in the interest of security to allow this kind of experimentation to
occur.

>   IMO, it's negligent to configure a firewall to pass traffic
> whose meaning is not known.

That means no end host to end host encryption that the network
firewall cannot understand.

...and for anyone else who likes to block unknown bits, then don't
let me see or hear you complain about how the net sucks, because you
are not letting it evolve so that it can be fixed.  :-)

John

RE: Smallest Transit MTU

[David Schwartz]

> It's not just that ECN isn't supported that is the problem, it's when
> systems by default reject packets with reserved bits set.   While you
> may pan ECN, it or something else that might enhance Internet protocols
> like it in the future should typically be silently ignored by end hosts
> that don't understand them so those experiments can at least take place.
>
> John

I, for one, do not agree. End hosts and firewalls *should* reject all
traffic they don't understand. It's precisely to prevent our unintentional
participation (as end hosts) in such 'experiments' that we deploy such
filters. The problem is when the policies are not maintained (or are
deployed in inappropriate places like transit networks), not that they exist
in the first place.

IMO, it's negligent to configure a firewall to pass traffic whose 
meaning
is not known. Of course, it's also negligent to leave a firewall configured
to block traffic whose meaning is known and is known to be desirable and
harmless.

DS

Re: Smallest Transit MTU

[Dan Hollis]

On Thu, 30 Dec 2004, Florian Weimer wrote:
> * Dan Hollis:
> > Because tcp connection endpoints have to implement ECN in order to manage 
> > the flow.
> Your wording suggests that ECN is purely an end-to-end signaling
> protocol

it does? where?

> (and so does a lot of propaganda from the ECN zealots).

an "ecn zealot" is someone who wants firewalls to work correctly? someone 
who wants idiots to stop blocking all icmp a  "pmtud zealot"?

> But is this really true?  If I read the RFC correctly, you need *routers*
> that use ECN to indicate congestion instead of packet drops.

anything along the path can *indicate* congestion, but its up to the 
*endpoints* to *respond* to the ECN indication and mitigate their flows.

read rfc3168 paying close attention to 6.1.2 and 6.1.3

-Dan

Paradyne or Occam DSL Equipment

[Shane Owens]

Is anyone using the Paradyne Net to Net product or Occam's BLC to provide DSL 
service?  Please contact me off list.

Shane Owens
shaneowensdna-communications.com

Re: Smallest Transit MTU

[John Kristoff]

On Thu, 30 Dec 2004 01:00:22 -0500
"Robert E.Seastrom" <[EMAIL PROTECTED]> wrote:

> A naive reader might think from Dan's posting that the Internet didn't
> work at all before ECN was codified (experimental with RFC 2481 in
> January 1999 and standards-track with RFC 3168 in September 2001).
[...]
> ECN has always looked to me like a solution in search of a problem,
> which may be why so few people have their panties in a bunch over
> non-support of it.

It's not just that ECN isn't supported that is the problem, it's when
systems by default reject packets with reserved bits set.   While you
may pan ECN, it or something else that might enhance Internet protocols
like it in the future should typically be silently ignored by end hosts
that don't understand them so those experiments can at least take place.

  

I also suspect that a very small population of users who would benefit
from ECN are hanging out in places like NANOG so your view of ECN
desirability may be limited.

John