Subject: Re: Draft on Advice for Internet Subnetwork Designers

From: Joe Touch <[email-masked]>
Date: Wed, 1 Mar 2000 10:11:55 -0800 (PST)

> From [email-masked]  Wed Mar  1 05:12:19 2000
> Date: Wed, 01 Mar 2000 13:30:30 +0100
> From: Dr G Fairhurst <[email-masked]>
> To: touch <[email-masked]>
> CC: [email-masked]
> Subject: Re: Draft on Advice for Internet Subnetwork Designers
> 
> More clarification...
> 
> Joe Touch wrote:
>
> > > "Falk, Aaron" wrote:
> > >
> > > PAGE 4: MTU Size
> > >
> > > It may be useful to note that using IPSEC in tunnel mode can increase
> > > the size of a packet as it travels across the network.  This can result
> > > in a smaller MTU.
> >
> > Doesn't IPSEC in any mode do this? (tunnel or transport?)
> >
> > (provided it's added after the source - and, in the case
> > of overlay networks, [paradoxically] transport may be
> > more useful)
> 
> Sure, you are correct. But, I seem to remember the draft mentioning 1500B MTU.
> Now, since this is a link designer's draft, what we are presumably interested in
> is frame payload data size... So, if normal IP is used that is maximum 1500B.
> If IPSEC is used end-to-end that is still 1500B of frame payload, even though
> MTU is reduced. But with tunnel mode along part of the path, the rest of the
> path outside the tunnel now sees a reduced MTU - or the tunneled path needs
> to support a larger frame size.  Just saying 1500B is not a
> universal MTU anymore.

It doesn't matter where IPSEC is used - E2E or tunnel. Either
way eats into the MTU. The PILC doc is talking about link MTUs;
everything except the link header consumes that.

> > > IPv6 does
> > > not therefore implement a network level integrity checksum. The role of the
> > > IP checksum has therefore been subsumed into the TCP and UDP
> > > checksums.
> >
> > More into IPSEC than into TCP and UDP, no?
> 
> IPSEC is one way, it is not (I think) mandatory, so TCP/UDP may still get
> bad packets which they have to reject....

Support for IPSEC is mandatory in IPv6, which is where the IP checksum
has been removed. Its _use_ is not mandatory. 

The role of the IP checksum was to check the IP header. The role of
the TCP/UDP checksums is to check the data. If you want to protect/sum
the header, you should (and thus, above, can) use IPSEC.

Joe

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 1 Mar 2000 18:46:28 +0000 (GMT)

On Wed, 1 Mar 2000, Joe Touch wrote:
> Gorry wrote:
> > > Gorry wrote:

No.

> > bad packets which they have to reject....

Yes. Of course, since the TCP/UDP checksum is weak, there's a chance
that a bad packet may slip through.

> Support for IPSEC is mandatory in IPv6

oh, whoopee. This Will Ensure IPSEC's Success.

> which is where the IP checksum
> the TCP/UDP checksums is to check the data.

Sorry, no. The TCP/UDP checksums still check the integrity of
significant parts of the IP header, even with IPv6. Remember the
"pseudo-header"?

Read RFC2460 section 8, page 26.

It is this check which adequately makes up for the IP header checksum
(which would have been a pain in IPv6, what with extension headers).

> If you want to protect/sum

Sorry, no. Use of IPSec is not necessary. Useful header integrity
checks come with the standard UDP/TCP pseudo-header check in IPv6, and
including pseudo-headers in checksums is an expected feature of any
IPv6 transport protocol.

L.

personal doubt is a powerful and accurate weapon.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Dr G Fairhurst <[email-masked]>
Date: Thu, 02 Mar 2000 15:43:15 +0100

I know this is in danger of getting really side-tracked, and what you say is
interesting, but
the subnet link designer is interested in subnet payload size, not just MTU.  What I
meant to
say was there are conditions under which the payload size is reduced, because a PMTU
smaller than the link MTU was selected by PMTU discovery.

Gorry

---

From: Joe Touch <[email-masked]>
Date: Fri, 10 Mar 2000 09:28:22 -0800

Regarding MTU assumptions...
Gorry Fairhurst and I went a round on this off-line;
here are our thoughts.

Joe

--------

Issue:

The concept of link MTU becomes fuzzy or nonexistent in today's
Internet.
The use of security, tunneling, and other header augmentation
over subpaths can substantially affect
the size of link MTU, even while a connection is in progress.

As a result, references to specific link MTU sizes, e.g., 1500B, may
not be appropriate. A designer attempting to achieve that size on
a single link will certainly have their efforts thwarted by IPSEC or
IPIP tunneling, among others.

In other words - even IP is a link layer, in IPSEC and in IPIP.
The best thing a link designer can do about MTU is _assume it can
change_.

---

From: Cannara <[email-masked]>
Date: Fri, 10 Mar 2000 11:31:55 -0800

Good.  Why not add that the MTU at the lowest layer should be large enough to
handle all known tunnellings of all other bottom layers.  Otherwise,
fragmentation must be handled there, as it has been for FDDI/Enet or
Token/Enet bridging?

Phil's comment about MD5, etc. completion checks is a good recommendation, and
the session layer has that as a logical responsibility, to be done often
enough that it fits users' timescales of activity.

Alex

---

From: Joe Touch <[email-masked]>
Date: Fri, 10 Mar 2000 14:29:00 -0800

Cannara wrote:
> handle all known tunnellings of all other bottom layers.

This can't be determined a-priori, i.e., by the link designer.

Big is good; if not big (or anyway), then either support fragmentation, 
or preferably support PMTU. Don't do anything that assumes knowledge of
the MTU before it can be determined.

Joe