Subject: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue

From: Pekka Savola <[email-masked]>
Date: Sun, 7 Mar 2004 18:24:27 +0200 (EET)

[ Moderators note: Post by non-subscriber.  With the massive amount of
   spam, it is easy to miss and therefore delete relevant posts 
   by non-subsrcibers. Please fix your subscription addresses. ]

Hi,

[[ note: I'm not subscribed... ]]

I took a quick look at the DNSSEC intro document; it was in a very
good shape.

Two major comments:

 1) the document requires the use of EDNS0.  However, current EDNS0
implementations typically advertise the larger sizes than they can
handle at the IP layer, causing fragmentation.  You can argue that
this is OK as long as the result of NOT fragmenting would end up with
a worse result than as you would be without it (e.g., requiring
falling back to TCP, or whatever).

With DNSSEC, I'm not sure that this holds anymore.  It seems to me
that the best behaviour would be to avoid IP fragmentation by having
correct implementations of EDNS0, and if some data must be left out,
that it would be fetched separately, over second, third, ..., nth
query over UDP.  Shouldn't that be possible and reasonable?

 2) Security considerations lists a number of threats, but does not 
discuss whether they have been fixed or mitigated at all (e.g., 
relating to dynamic updates and signing).  It might not hurt to be a 
bit more explicit on this.  Similarly, maybe some of this text could 
be included in the DNS security analysis document as well...

editorial
---------

page 4, chapter 2, replace "RRsets forms" with "RRsets forming"

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

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Paul Vixie <[email-masked]>
Date: Mon, 08 Mar 2004 03:09:22 +0000

> falling back to TCP, or whatever).

most of <http://research.compaq.com/wrl/techreports/abstracts/87.3.html>'s
concerns about fragmentation have been addressed, and the ones which still
apply are relevant to small-mtu connections ("don't do that") and to high
performance/demand mobygram applications (nfs, tcp).  for dns, it's okay.

> query over UDP.  Shouldn't that be possible and reasonable?

no, that really would force tcp, which really would be worse than ip-frag.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 08 Mar 2004 13:47:21 +0900

Paul;

> no, that really would force tcp, which really would be worse than ip-frag.

If message size is 1400B or so, it is definitely so.

If message size is 4200B or so, it can still be a valid argument.

However, if message size is 64000B, TCP is far better than IP-frag.

I understand the problem is not of DNSSEC but of EDNS0.

But with the current EDNS0 specification lacking rational upper
limit on message size, it will be safe if DNSSEC says:

	messages over UDP MUST NOT be larger than 4000

							Masataka Ohta

---

From: Paul Vixie <[email-masked]>
Date: Mon, 08 Mar 2004 05:02:50 +0000

> However, if message size is 64000B, TCP is far better than IP-frag.

yes, that's true.  the crossover is probably closer to 4*PMTU.

> 	messages over UDP MUST NOT be larger than 4000

it can't be a MUST NOT or it modifies the EDNS0 spec, which is out of scope.
perhaps we should reissue EDNS0 with a recommendation like 4*EPMTU (where E
is for Estimated) but this isn't the time or place to make that change.

so perhaps an advisory statement like "Note: advertising a buffer size larger
than EPMTU could lead to unfortunate overaggressive IP fragmentation" would
be enough to tell the dnssec implementor crowd -- who is likely to be the
first real stress-testers of EDNS0's buffer size extension -- what they need
to know, without actually amending the EDNS0 specification by side effect.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 08 Mar 2004 14:58:13 +0900

Paul;

> it can't be a MUST NOT or it modifies the EDNS0 spec, which is out of scope.

I meant

	DNSSEC entities MUST NOT send messages larger than 4000
	over UDP

Can it be within the scope of DNSSEC?

> is for Estimated) but this isn't the time or place to make that change.

If EDNS0 is to be changed (in the future, of course), reference
to PMTUD should be clarified (removed entirely), because EDNS0
seemingly assumes fragmentation is always enabled, which means
there is no room for PMTUD, which means, with IPv6, packets must
be fragmented at the source.

Or, if you think some form of PMTUD should be performed, it should
be documented (though I think PMTUD practically impossible).

> to know, without actually amending the EDNS0 specification by side effect.

:-)

							Masataka Ohta

---

From: Paul Vixie <[email-masked]>
Date: Mon, 08 Mar 2004 06:26:31 +0000

> > ... would force tcp, which really would be worse than ip-frag.
> 
> Seems like a flaw in DNS spec -- too coarse granularity:
>  1) "everything fits in one UDP datagram", or
>  2) "just use TCP".
> 
> Would it make sense to add 1.5) there, "if it doesn't fit to a UDP 
> datagram of specific size, query again, but only the missing data this 
> time".

sense, yes, but the atomicity requirements are hard to adjust in that light.

for example, if what you're trying to send is a referral, and the query and
authority sections are all that fits, and you decide to just send that much
and let the initiator re-query for the parts that would have been in the
additional-data section, then it might end up being the case that they can
never query for it.  consider an authority section whose names are all under
the referral cut.

in earlier work once proposed as part of EDNS0 and then reintroduced as EDNS1,
the idea came up to indicate in a response that there were multiple messages
in the answer.  we called it MD ("more data").  ultimately this turned out to
be a lot more complicated than it sounded, and it's since been abandoned.

i dearly wish that EDNS0 had made TTCP its prerequisite.  ("ah, hindsight.")

> Not sure if that would make sense but instead of forcing everything in 
> one, probably fragmented message, it would seem to encourage "proper" 
> operation with big DNS replies.

in general, if you think the response might be larger than 3*EPMTU, use tcp,
and that will amortize the complexity nicely.  note that PMTUD hasn't been a
raging success, and that EPMTU is probably 1500 octets most of the time, and
that's where masataka's "4000" number comes from.

> Btw: note that IPv6 implementations aren't even required to defragment 
> a datagram which is larger than 1500 bytes once assembled.. so we're 
> in a bit murky waters here.  I'd certainly want to try to avoid packet 
> sizes >= ~1500.

yes but on such a host, the EDNS0 initiator would presumably be able to 
discover this limitation and advertise a 1500-octet buffer.  that's what
the EDNS0 spec says it should do, at any rate.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 08 Mar 2004 06:29:28 +0000

> Can it be within the scope of DNSSEC?

then it would be within scope for this docset, but extremely controversial
since it places a requirement more stringent than EDNS0.  far better to make
it advisory and avoid the fight.

> > perhaps we should reissue EDNS0 with a recommendation like 4*EPMTU
> > (where E is for Estimated) but this isn't the time or place to make
> > that change.
> 
> If EDNS0 is to be changed (in the future, of course), reference to
> PMTUD should be clarified (removed entirely), because EDNS0 seemingly
> assumes fragmentation is always enabled, which means there is no room
> for PMTUD, which means, with IPv6, packets must be fragmented at the
> source.
> 
> Or, if you think some form of PMTUD should be performed, it should be
> documented (though I think PMTUD practically impossible).

i think that you're right and that all hope of PMTUD should be abandoned
in the next update of EDNS, which at this point would be EDNS1 rather than
a reissue of EDNS0.

---

From: "Scott Rose" <[email-masked]>
Date: Mon, 8 Mar 2004 09:59:49 -0500

----- Original Message ----- 
From: "Paul Vixie" <[email-masked]>

> it advisory and avoid the fight.

It would also be an arbitrary limit based on current underlying network
layers.  The 4000 byte limit is not really a bound by DNS (with DNSSEC) or
EDNS0.  It would best not be made a strict constraint that might be made
obsolete by non-DNS factors.  I agree with Paul in that it would be better
to be an advisory statement, but not necessary to the specification.

Scott

---

From: Pekka Savola <[email-masked]>
Date: Mon, 8 Mar 2004 07:37:47 +0200 (EET)

---

From: Pekka Savola <[email-masked]>
Date: Mon, 8 Mar 2004 09:41:34 +0200 (EET)

On Mon, 8 Mar 2004, Mark Andrews wrote:
> 	What's your issue here?
> 
> 	IPv4 has reassembly buffer size limits.
> 	IPv6 has reassembly buffer size limits.	
> 
> 	In either case you don't advertise a EDNS UDP buffer bigger
> 	than this limit.

It would be nice if EDNS0 implementations conformed to these buffer 
sizes then.

Currently it seems they have zero relation to MTU or PMTU, or buffer
sizes.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 08 Mar 2004 19:10:10 +1100

> It would be nice if EDNS0 implementations conformed to these buffer 

	On what platforms do the existing implementation not take
	these into account.  Note most *nix platforms support 4k
	UDP datagrams already.
 
> Currently it seems they have zero relation to MTU or PMTU, or buffer

	There doesn't have to be a *explict* relationship to these.
	The current recommendations already take these into account.
 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Mon, 08 Mar 2004 17:58:33 +1100

What's your issue here?

	Mark

---

From: Pekka Savola <[email-masked]>
Date: Mon, 8 Mar 2004 18:25:16 +0200 (EET)

> sense, yes, but the atomicity requirements are hard to adjust in that light.

Precisely -- but IMHO we need to figure out whether such atomicity 
requirements exist.  They very certainly exist with 512 byte limit and 
DNSSEC.  But do they exist e.g., with 1400 bytes?  I'm a bit 
doubtful.. but I'd be interested in hearing what might be a "typical 
case", a "bad case", and "worst case".  (We'll never be able to handle 
the last one, of course.)

> that's where masataka's "4000" number comes from.

Yep, EPMTU is 1500 bytes or a bit less -- but isn't that sufficient 
for about all intents and purposes?

> the EDNS0 spec says it should do, at any rate.

Should, yes :).  Does, no.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 8 Mar 2004 18:21:20 +0200 (EET)

> 	these into account.  Note most *nix platforms support 4k

I don't know, maybe some embedded systems have restrictions.

In any case 4000 byte UDP buffers does not equal being able to 
defragment datagrams worth of 4000 bytes total, right?

> 	The current recommendations already take these into account.

Well, about all the implementations I've seen set the EDNS0 
irrespective of the MTU or PMTU configured on the system, which might 
make sense.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 09 Mar 2004 05:41:18 +1100

> I don't know, maybe some embedded systems have restrictions.

	Well if you are writing a resolver for such a system
	you take its IP stack limitations into consideration.
	There are lots of additional considerations when
	writing for small memory platforms.
 
	Nobody is saying you *MUST* use certain size, just that
	they are recommended.  Named has a switch to set the
	advertised size to 512.

> irrespective of the MTU or PMTU configured on the system, which might 

	With the current Internet the min(MTU,PMTU) will usually
	be 1500, ethernet/ppp default.  Rarely will it be below 1200,
	slip default.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 09 Mar 2004 08:02:38 +0900

Scott Rose;

> EDNS0.

512 byte limit is a bound not by DNS but by the current underlying
network and transport layers.

So?

> but not necessary to the specification.

It is necessary that DNS message size has a limit in the specification.

							Masataka Ohta

PS

The proper limit bound by minimum reassembly buffer size, maximum
IP header length and UDP header length is 508.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 09 Mar 2004 08:46:37 +0900

Mark Andrews;

> 	Why are we arguing about the minimums that have to be
> 	supported by the architecure?

Because the minimums of the infrastructure are maximums of DNS.

> 	For example, named has a upper bound on the size of the
> 	EDNS/UDP response it will send.

And, it should be specified.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 09 Mar 2004 09:38:11 +0900

Mark Andrews;

> 	EDNS and DNS are *different* protocols which share a port and
> 	message format.

RFC2671

   This
   document describes backward compatible mechanisms for allowing the
   protocol to *GROW*.

						Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Tue, 09 Mar 2004 10:35:24 +1100

EDNS is about letting the the other end knowing what you
	are *capable of handling*.  There is *nothing* in to stop
	a site sending *smaller* EDNS/UDP message than the receiving
	site is capable of handling.

	If the client says it can accept a 4k response but you know
	that your firewall is broken (e.g. drops DNS packets > 512)
	you are quite entitled to only send a 512 byte EDNS/UDP
	responses.  Set TC as appropriate.

	For example, named has a upper bound on the size of the
	EDNS/UDP response it will send.  You can advertise a 64k
	UDP buffer all you want but you will not get more that 4k
	EDNS/UDP response.

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Tue, 09 Mar 2004 11:23:43 +1100

> Because the minimums of the infrastructure are maximums of DNS.

	We are talking about EDNS.  Nobody is thinking about changing
	the DNS UDP message size.  The DNS is constained in this way,
	EDNS is not.

	EDNS has a UDP request size limit of 512 bytes (inherited
	from DNS) unless you have reason to believe a larger request
	can be handled. e.g. you have just made a request and have
	been told that a bigger request can be handled.

	EDNS has a *negotiated* response size limit.  This is IP
	stack dependent and will usually be *bigger* than the
	infrastructure minimums.  It can also be smaller the the
	infrastructure minimums.  e.g. you have a IPv6 firewall
	which is rejecting DNS packets > 512 bytes so you set the
	EDNS UDP size advertised to 512.  The advertised EDNS UDP
	size is less than the minimum supported by the IPv6.

	DNS has a UDP request and response size limit of 512 bytes.
	
> And, it should be specified.

	Why.  This is a *implemtation* limit not a *protocol* limit.
	RFC 2671 already has guidance for seting this limit.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 9 Mar 2004 17:04:26 +0100

> falling back to TCP, or whatever).

It seems there _could_ be consensus for an advisory note targeted at
implementors, if only there were such a note.

Can somebody please come up with text that can be put into the
document set so we can focus on getting that correct and the editors
can cut-n-paste.

Let us not try to fix EDNS0, that is not in scope.

-- Olaf

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 13 Mar 2004 08:27:07 +0900

Paul;

> yes, that's true.  the crossover is probably closer to 4*PMTU.

Given 1280B of IPv6 minimum MTU, shouldn't message size limitation
be somewhere around 3600 or 4800, but not 4000?

						Masagtaka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 13 Mar 2004 08:48:52 +0900

> be somewhere around 3600 or 4800, but not 4000?

My guess is that current specification of 4000B expects
3 frags over IPv4 that it should be 3600B for IPv6.

						Masataka Ohta

---

From: Paul Vixie <[email-masked]>
Date: Sat, 13 Mar 2004 00:58:15 +0000

> be somewhere around 3600 or 4800, but not 4000?

i think it's all very approximate and 4000 is a very fine and round number.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 15 Mar 2004 14:08:17 +0900

Paul;

> i think it's all very approximate and 4000 is a very fine and round number.

It could have been so, if PMTUD were usable, which would have
resulted in PMTU of 1450~1500.

Without PMTUD, however, assumed MTU MUST be 1280, for which very
approximate and round should be 3500 or 3600.

Or, are there any cryptographic reason that the size is 4000?

							Masataka Ohta