Subject: [pmtud] draft-welzl-pmtud-options-00.txt

From: Michael Welzl <[email-masked]>
Date: 01 Dec 2003 12:34:24 +0100

Dear all,

I submitted my "PMTUD using options" idea as
draft-welzl-pmtud-options-00.txt -  a URL for this Internet-draft is:
http://www.ietf.org/internet-drafts/draft-welzl-pmtud-options-00.txt

I really would appreciate your comments as I would like to
contribute this to this working group.

Best regards,
Michael

_______________________________________________
pmtud mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmtud

---

From: Michael Welzl <[email-masked]>
Date: 03 Dec 2003 09:52:45 +0100

Hmmm ... no reaction so far...

Sure, there should be some controversy here?

C'mon: I'm proposing to take this up as a WG item, but I'm
trying to revive an idea from a historic RFC here! And
then there are all these disadvantages that you get from
IP Options ... some of you MUST be opposed to this!   :)

Seriously - it would help a great deal if we could get
a discussion going; I am serious about this contribution -
I think it could really help a great deal, at least in
special cases. Positive comments are just as welcome as
critique ...

Best regards,
Michael

-- 
Michael Welzl <[email-masked]>
University of Innsbruck

---

From: Eddie Kohler <[email-masked]>
Date: Thu, 04 Dec 2003 17:42:25 -0800

Michael,

On the one hand, most people probably think that anything involving IP
options will not happen in practice. On the other hand, this seems like a
perfectly reasonable/appropriate way to get precise MTU information
quickly. 

But it would be best to change the Probe MTU option format so that the
receiver can detect whether or not a router on the path ignored the
option. I'd suggest making the option size 9, and including a TTL byte, to
be initialized to the IP TTL value. Routers that process the option will
reduce the option TTL, whether or not they change the MTU. The receiver can
then compare option TTL with IP TTL; if they agree, everyone understood the
option, and the MTU value is safe, but if they didn't agree, someone didn't
understand the option, calling for a more conservative reaction.

Finally, what is the pmtud group aiming to do? Deprecate all PMTU discovery
mechanisms except PLPMTUD? (I think that would be a mistake.) Or describe
several PMTU approaches, including when they succeed and when they fail,
and suggest how they should be combined in practice? (I think that would be
best.) The option approach would only mesh with the second aim.

Eddie

---

From: "Michael Welzl" <[email-masked]>
Date: Sat, 6 Dec 2003 10:10:38 +0100

Hi Eddie,

Thanks a lot for answering! I surely hope to get some discussion
going here...

> understand the option, calling for a more conservative reaction.

I considered that for a while when I wrote the draft (the
same thing is part of my PTP protocol   :)   ), but then I figured
out that it wouldn't be too beneficial after all ... so I
dropped the idea.

Why?

Because the idea is to take the result as an upper limit for
PMTUD (or PLPMTUD). Assume that all routers supported the
option. If you do regular PMTUD, you use the value, get no
error feedback, no problem occurs, the mechanism has converged
right away, no benefit from knowing that all routers supported
the option in advance.

If you do PLPMTUD, you gradually increase your packets (quickly,
because it is based on a MTU table) and stop at the result -
again, no problem occurs.

The only advantage of knowing that the information is complete
would be with PLPMTUD - you could use the correct value right
away, and the scheme would converge faster. Well, that COULD be
a reason to use the TTL approach you describe, but is it?
How often will *ALL* routers support the option?

Well, for usage across tunnels, it might make sense...

What do the others think?

> best.) The option approach would only mesh with the second aim.

I favor the second aim, but I don't see why my approach wouldn't
work with the first aim (PLPMTUD only) - it is designed to work
with all kinds of PMTUD-type mechanisms anyway.

Best regards,
Michael

---

From: Fred Templin <[email-masked]>
Date: Fri, 05 Dec 2003 10:00:35 -0800

I'll give two thoughts on the subject for now, but won't be able to track
any further discussion until well after the beginning of the year due to
pressing obligations in other areas:

  1) Any PMTU information coming from an untrusted middlebox
    should be considered suspect.

  2) RFC 1122, section 3.3.3 under "DISCUSSION" gives a set of
    considerations for "Picking the correct datagram size to use when
    sending data" on IPv4 networks, and I firmly believe these
    considerations remain valid today. The only part of that section
    that I find somewhat ambiguous is the reference to RFC-1063
    in the final sentence; I believe the author's only intention was to
    make readers aware of an experimental approach of the day, and
    not to implicitly bless that approach.

Thanks - Fred
[email-masked]

---

From: Michael Welzl <[email-masked]>
Date: 09 Dec 2003 10:15:30 +0100

>     should be considered suspect.

I agree. Please see the "Security Considerations" section
of my draft for a discussion of such issues. In particular,
note that the security risk of my option is roughly similar
to the risk of ICMP Fragmentation Needed messages. Just like
these messages, the result from my option should only be
taken as a hint. Discussing the value of such a hint goes
back to our recent discussion on ICMP Fragmentation Needed
and doesn't really relate to my option in particular.

Also note that the security from my option is slightly
better than ICMP Fragmentation Needed: end2end IPsec
authentication can be used (doesn't help against
lying middleboxes), and there is a Nonce to reduce
the chance for a malicious intermediate node to
lie about upstream routers.

>     not to implicitly bless that approach.

I don't see how this section relates to my proposal.
And, BTW, I also don't think that the following statement
from this section remains valid today:

   Since nearly all networks in the Internet currently
   support an MTU of 576 or greater, we strongly recommend
   the use of 576 for datagrams sent to non-local networks.

;-)

... this was before PMTUD.

Best regards,
Michael