Subject: Re: Last Call: draft-manner-router-alert-iana (IANA Considerations for the IPv4 and IPv6 Router Alert Option) to Proposed Standard

From: Robert Elz <[email-masked]>
Date: Thu, 10 Jul 2008 23:08:12 +0700

Date:        Wed,  9 Jul 2008 09:41:03 -0700 (PDT)
    From:        The IESG <[email-masked]>
    Message-ID:  <[email-masked]>

  | The IESG has received a request from an individual submitter to consider
  | the following document:
  | 
  | - 'IANA Considerations for the IPv4 and IPv6 Router Alert Option '
  |    <draft-manner-router-alert-iana-03.txt> as a Proposed Standard

Two comments.

First (last sentence of section 2):

   It is unclear why nesting levels begin at 1 for IPv4 (described in
   section 1.4.9 of [RFC3175]) and 0 for IPv6 (allocated in section 6 of
   [RFC3175]).

isn't the kind of sentence that belongs in a doc like this.   If the
authors are mystified, just omit the sentence, including it adds nothing.
Better, of course, would be to ask, and discover, and provide an
explanation.

But, this doc deletes aggregation level 0 from IPv6 anyway, which makes
all of this even stranger.

Second (section 4, security considerations):

   Yet, as discussed in RFC 4727 [RFC4727] production networks do not
   necessarily support the use of experimental code points in IP option
   headers.  The network scope of support for experimental values should
   carefully be evaluated before deploying any experimental RAO value
   [...]

This is the kind of thing we might have expected to see in a security
considerations section 15-20 years ago, when the network was a nice kind
friendly environment, where all the players would take great care not
to do anything that might cause a problem.

These days, if "the use of unsupported experimental code points" has the
"potential to disrupt the stable operation of the network" then that would
be something worthy of a CERT advisory and hasty code fixes by whatever
vendors are supplying the systems that would be disrupted.

It is never safe to assume that any random value won't appear in any
random field of a packet, and for just the same reason, there's no
reason for anyone to avoid using any particular value.   This security
consideration paragraph should simply be deleted.

The following one is more just common sense, wrt general management, and
also exposes no security issues, and should probably be deleted as well.

All of this (except the first paragraph which is fine) smells very much
like an attempt to provide some meaningful security considerations section
just because meaningful security considerations sections are required
(by someone, for something) even where it's absurd to imagine any security
issues that can really apply.

If real security considerations were to be discussed in a doc that just
establishes an IANA registry, and does no more than that (doesn't create
new values with meanings that didn't already exist, etc) then about all
that could be really said would be abut spoofing messages to IANA
causing bogus values to be allocated, and/or adequately protecting the
registry content so it is known that what is observed there is in fact
correct - but none of that is really worth having in every RFC that
happens to create a new IANA object.

Personally I'd prefer to simply see the meaningless security considerations
section removed completely from this doc (but of course, there's a "rule"
that says it must always be present, even when it is stupid, and obeying the
rules is, of course, far more important than producing quality documents...)

kre

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

---

From: "Joe Baptista" <[email-masked]>
Date: Thu, 10 Jul 2008 15:26:36 -0400

> to do anything that might cause a problem.

Those days are long gone.  Unfortunately were stuck with that
infrastructure.  Its good infrastructure - but not well policed - and
insecure as hell because too many people built a system that assumed trust
was the default value.

> vendors are supplying the systems that would be disrupted.

Ya - I hear you - but this way its a good way to sell DNSSEC and put
Verisign in charge of the DNS keys.  No thank you.  But its worth watching
what happens.

(but of course, there's a "rule"
> rules is, of course, far more important than producing quality

Yes - we are only human.  Rules are good.  That does not mean rules can not
be questioned.  And changes made by consensus.

cheers
joe baptista

-- 
Joe Baptista
www.publicroot.org
PublicRoot Consortium
----------------------------------------------------------------
The future of the Internet is Open, Transparent, Inclusive, Representative &
Accountable to the Internet community @large.
----------------------------------------------------------------
Office: +1 (360) 526-6077 (extension 052)
Fax: +1 (509) 479-0084
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf