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

[Jari Arkko <[e-mail]>]

[e-mail] wrote:

>>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.

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?

>>For Section 8, RFCs 2401, 2402, and 2406 are currently being 
>>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.

>>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.

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.

>>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.

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.

> 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" ?

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.

>>  But maybe the sentence is not needed at all. The two MODULE-COMPLIANCEs
>>  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...

>>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.

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


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