Subject: FW: Evaluation of: draft-ietf-ipv6-node-requirements-07.txt

From: [email-masked]
Date: Tue, 23 Dec 2003 12:20:37 +0200

Hi all,

The node requirements draft was reviewed by the IESG.  Here are
the main points raised, arranged by reviewer.

The big issue I see is about upgrading IKE to a SHOULD.  

I'll try to start addressing the points after Christmas, but feel
free to discuss it already.

Set 1:

> I'm astonished that Path MTU is a MAY -- I had thought it was 
> a MUST.  I'd really like some more text explaining what some 
> of the many exceptions are that are alluded to here.
> 
> For Section 8, RFCs 2401, 2402, and 2406 are currently being 
> revised by the IPsec group; that should be mentioned.
> 
> The crypto algorithm requirements should be better aligned 
> with recommendations from the IPsec wg.  There's a draft that 
> lists 3DES as SHOULD, not MAY.
> 
> I think that IKEv? should be a SHOULD, not a MAY.  While the 
> IESG hasn't yet seen draft-bellovin-mandate-keymgmt, it will 
> soon and it describes automated key management as a "strong 
> SHOULD".  That's certainly the consensus in the security area.
> 
> More generically, I don't think that this WG should 
> standardize weaker security requirements than the security 
> area thinks are appropriate, without strong justification.  
> (Stronger requirements are fine -- they may have a different 
> operational environment, or a different threat model.)

Set 2:
 
> 1. Section 10.1.1 talks about "IP Forwarding Table MIB"
>   The revision of this MIB document (that you refer to) has a number
>   of deprecated and obsoleted objects. I think what you want (intend)
>   to say is that an agent must implement those objects that are
>   required as per ipForwardFullCompliance or ipForwardReadOnlyCompliance.
> 
>   I am also not sure that this is correct:
>       Support for this MIB does not imply that IPv4 or IPv4 specific
>       portions of this MIB be supported.
>   Did you mean "IPv4 or IPv6 specific portions" ?
>   But maybe the sentence is not needed at all. The two MODULE-COMPLIANCEs
>   that I point you to above specify IP version neurtral objects!
> 
> 2. Similar comments/issue with Sect 10.1.2
>   I think you want to refer to CURRENT MODULE-COMPLIANCE, namely 
>   ipMIBCompliance2. Pls check and make sure you be specific as to what
>   needs to be supported.

Set 3:

> One bigger issue, which may not be worth a Discuss, but 
> something that 
> IMHO should be discussed in some forum:
> 
>         All nodes that need to resolve names SHOULD implement stub-
>   resolver [RFC-1034] functionality, in RFC 1034 section 5.3.1 with
>   support for:
>                                                               
>     - AAAA type Resource Records [RFC-3596];
>     - reverse addressing in ip6.arpa using PTR records [RFC-3152];
>     - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512
>       octets.
> 
> .. I'm operationally concerned about the last SHOULD.  As far as I 
> know, EDNS0 is not really implemented.  It does not seem to include a 
> SHOULD to something that hasn't seen practical, wide-spread deployment 
> already.  I'd recommend removing this or rewording it to a MAY.

John

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Jari Arkko <[email-masked]>
Date: Tue, 23 Dec 2003 14:46:20 +0200

>>of the many exceptions are that are alluded to here.

It follows RFC 2460, which states:

    It is strongly recommended that IPv6 nodes implement Path MTU
    Discovery [RFC-1981], in order to discover and take advantage of path
    MTUs greater than 1280 octets.  However, a minimal IPv6
    implementation (e.g., in a boot ROM) may simply restrict itself to
    sending packets no larger than 1280 octets, and omit implementation
    of Path MTU Discovery.

Given this, I'm not sure we can convert it to a MUST. But
did you have some specific text issues about the Path MTU
text as well?

>>revised by the IPsec group; that should be mentioned.

Ok. I agree that it is good to alert the reader to the
fact that some of the documents may have updated RFCs
available. Thanks.

>>lists 3DES as SHOULD, not MAY.

The problem is that the requirements have been aligned with
the recommendations of the IPsec, as they exist in *RFCs*.
Not drafts.

I personally think that we need to recommend and inform
about better alternatives, even if such alternatives do not
yet exist as RFCs or if they are not mandated by keywords.
This is what we have done -- the document talks about 3DES,
AES, etc.

However, there has been general resistance in the WG (maybe even the
ADs) for us to mandate anything beyond the current normative RFCs. It
was felt that the original RFCs should rather be updated than the
node requirements document made to impose additional requirements.
If the IESG thinks its okay for us to mandate stronger algorithms
than what the current IPsec RFCs say, then I'm going to be
*very* happy.

But if, not then I think its up to the IPsec WG to advance their
documents and mandate the algorithms that they think are
appropriate.

>>SHOULD".  That's certainly the consensus in the security area.

This is also related to the question of what the current
RFCs say. In the case of IKE, I'm actually uncertain what
the keyword is -- it is not immediately clear to me from the
document. Perhaps it is to others, I would appreciate comments
on this! I think we should use a keyword that the current
RFCs have, whatever that is.

Anyway, I think the node requirements document is somewhat
different than a usual IETF protocol document. In the RFC for
for protocol FOO, there are some security issues and those
are solved with the support of some security mechanisms.

But here, the specific security issues appear within the
RFCs that we refer to, and the necessary security mechanisms
are introduced there as well. So when talking about FOO
and IKE, we know that IKE addresses FOO's issues. But in
the case of the node requirements document, the security
issues either have been addressed in the relevant RFCs, or
those RFCs should be reissued and corrected.

Additional stuff can be extremely useful for the nodes, but it
may not address any IPv6-specific issue. For instance, if we
required IKE, TLS, and S/MIME, this would make sure that
those are available to the IPv6 nodes, but none of them would
help addressing the security issues in, say, IPv6 ND.

So I guess what I am looking for is some guidance on whether
this document should focus on the IPv6 specific part, or give
a more general requirements. I think we need to choose between

  (1) "We, the IETF, think that in order to do IPv6, you
      need <THIS>.", and
  (2) "We, the IETF, think that in order to do IPv6, you
      need <THIS> and the user on a node surely needs
      also <THAT>."

I'm fine doing it either way, but we need to agree what
the scope is.

>>  Did you mean "IPv4 or IPv6 specific portions" ?

I think the intent was to say that if you implement IPv6 and as a
result also the forwarding table MIB, it does not follow that you also
have to implement all of IPv4.

>>  that I point you to above specify IP version neurtral objects!

I'm glad to hear that its IP version neutral.

So what happens if I create a new InetCidrRouteEntry and
set inetCidrRouteDestType to "ipv4" on a box that supports
only IPv6?

What I would like to happen is that this would fail, and
doing so would not mean that the box violates 2096bis...

>>already.  I'd recommend removing this or rewording it to a MAY.

This is very useful input. I'd go for a MAY if this is the case.

Question: is it the infrastructure part, the clients, or both that
do not implement EDNS0?

--Jari

---

From: [email-masked]
Date: Wed, 24 Dec 2003 00:30:52 +1100

> > already.  I'd recommend removing this or rewording it to a MAY.

	Define "not really implemented".

	RFC 2671 was published August 1999.
	Production servers w/ EDNS0 were release Jan 2000.
	The root servers have been EDNS aware for over a year if memory
	serves me.  There is still one holdout (B).

	Even the load balancer cowboys are implementing EDNS0.
	Their server's may not understand MX/NS/SOA/AAAA but they
	do understand EDNS queries.

	Over half the servers on the net currently talk EDNS based on
	the figures I have seen.

	The majority of the problems come from servers that fail to
	implement RFC 1034 by dropping EDNS queries and firewalls that
	either reject additional records in queries or reject UDP answers
	bigger than 512 octets.  Retrying the query w/o EDNS on timeout
	addresses these.

	The firewall vendors now have code that is EDNS aware.
	Most of the servers that dropped EDNS queries were load balancers.
	While we still have to win the battle to get them to understand
	AAAA.  They appear to have seen the light on EDNS.

	I have no problem with a SHOULD for stub resolvers.  While most
	don't do it there is real unknowns in saying that they should
	do it.  The caching server they are using most probably is already
	making EDNS queries on their behalf.

	Mark

--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Tue, 23 Dec 2003 16:53:43 +0200 (EET)

On Wed, 24 Dec 2003 [email-masked] wrote:
[...]
> 	don't do it there is no real unknowns in saying that they should

While DNS servers seem to have added support for EDNS0, the stub
resolvers don't seem to be supporting at least widely (e.g., at least
BSD, Linux and Win2K don't).  At least looking around with tcpdump, I
see *very* little UDPsize options in DNS packets, probably coming from
newer DNS servers out there which have toggled on the option in their
config.

EDNS0 is probably a nice thing to have, but as far as I can see,
generic nodes don't seem to be doing it now (which is what the doc
talks about).  I guess the question is about whether we want to
encourage adding that support, or documenting existing, well-known
practice for new implementations.  If we put EDNS0 as a SHOULD, we'd
probably be doing the former .. which is OK by me as long as we're
doing a conscious decision on that (but my personal take is that we
should stick to "known good, implemented, works" -mantra in a document
like this).

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

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 24 Dec 2003 00:36:21 +0900

>>>>> On Tue, 23 Dec 2003 16:53:43 +0200 (EET), 
>>>>> Pekka Savola <[email-masked]> said:

> newer DNS servers out there which have toggled on the option in their

A minor correction: the resolver library in *BSDs libc should support
for EDNS0, at least in their latest releases.  EDNS0 in the resolver
is disabled by default, though.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Mans Nilsson <[email-masked]>
Date: Sun, 28 Dec 2003 10:54:12 +0100

Subject: Re: FW: Evaluation of: draft-ietf-ipv6-node-requirements-07.txt Date: Tue, Dec 23, 2003 at 04:53:43PM +0200 Quoting Pekka Savola ([email-masked]):

> <snip>  I guess the question is about whether we want to

We know that EDNS0 works. Mark did a good description of the present
state. I see nothing to the contrary. It is A Good Thing to endorse
EDNS0 in a document like this, because it could speed up deployment. 

-- 
Måns Nilsson         Systems Specialist
+46 70 681 7204         KTHNOC
                        MN1334-RIPE

Now I think I just reached the state of HYPERTENSION that comes JUST
BEFORE you see the TOTAL at the SAFEWAY CHECKOUT COUNTER!

---

From: Thomas Narten <[email-masked]>
Date: Tue, 30 Dec 2003 11:52:04 -0500

>     sending packets no larger than 1280 octets, and omit implementation

Seems to me, given the above wording, 2460 says Path MTU is a SHOULD,
not a MAY. Note that the MAY is about _not_ implementing it (in some
situations), not a "MAY" implement it in some subset of the comment
cases.

I.e, if node-requirements says MAY, I think that is a downgrade from
the SHOULD in 2460 as quoted above. I don't think this document should
be doing that.

Thomas

---

From: Jari Arkko <[email-masked]>
Date: Tue, 30 Dec 2003 22:51:21 +0200

Thomas,

> the SHOULD in 2460 as quoted above. I don't think this document should

I agree that the node requirements document should follow what 2460
says.

Taking a new look at a the text, it does indeed sound more like a
"SHOULD normally implement but MAY not implement in some cases".

RECOMMENDED is a synonym for SHOULD, and upper/lower case usually (?)
should not matter when interpreting protocol requirements.

Suggested node requirements text change:

    4.3.1 Path MTU Discovery - RFC1981

    Path MTU Discovery [RFC-1981] MAY be supported.  It is expected that
    most implementations will indeed support this, although the possible
    exception cases are sufficient that the used of "SHOULD" is not
    justified.  The rules in RFC 2460 MUST be followed for packet
    fragmentation and reassembly.

=>

    4.3.1 Path MTU Discovery - RFC1981

    Path MTU Discovery [RFC-1981] SHOULD be supported, though minimal
    implementations MAY choose to not support it and avoid large packets.
    The rules in RFC 2460 MUST be followed for packet fragmentation and
    reassembly.

--Jari