Subject: [Hipsec] Submitting draft-moskowitz-hip-arch-05 to the RFC EDITOR

From: [email-masked] (Pekka Nikander)
Date: Mon Oct 20 02:13:01 2003

Folks,

I am shortly planning to submit draft-moskowitz-hip-arch-05.txt
directly to the RFC EDITOR to be published as an Informational
RFC, as per RFC2026 Section 4.2.3.  The current version of the
draft is available at the URLs listed in the bottom of this message.

As far as I can tell, I have taken care of all the issues
that were noticed during our informal last call.  I have
marked Issues #2-#4 as Closed.  Issues #1 and #5 are still
as Proposal, since there *may* be additional discussion that
needs to be closed.

The planned schedule is as follows:

   Now:                     The pre-draft is available.

                            Wait for corrections based on the version
                            listed below.  Close issues #1 and #5.

   Wed, Oct 22, 9am GMT+2:  Submit the draft to the drafts repository.
                            Announce the draft at ipsec, mipv6, miv4,
                            multi6, and ietf-discuss.

                            Wait for comments.  I don't expect any
                            substantial ones, but there may be editorial
                            things that need to be clarified.  There may
                            also ensue discussion, but such discussion
                            should not slow down the draft.

   Mon, Oct 27, morning:    Submit the draft directly to the RFC Editor,
                            CC:in the IESG.

Per RFC2026 Section 4.2.3, the RFC editor will wait for two two weeks
for comments, and consult the IESG.  I have no idea how the IESG will
react or how timely their reaction will be.  However, if everything
goes smoothly (which is possible but not very likely), the document
might get an RFC number already during the Minneapolis meeting.

The pre-draft is available at the following URLs.

http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05-pre-Oct20.txt
http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05-pre-Oct20.html
http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05-pre-Oct20.xml
http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05-pre-Oct20-chbar.txt
http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05-pre-Oct20-diff.html

--Pekka Nikander

---

From: [email-masked] (Pekka Savola)
Date: Mon Oct 20 02:33:01 2003

> draft is available at the URLs listed in the bottom of this message.
[...]

<lurker mode=off>

Prior to going down that path, I should perhaps ask whether the folks have 
considered what is the intended outcome of this action?

As the HIP protocol itself has been a bit of a moving target, I'm not 100% 
certain that publishing the document at this phase is really reasonable.  
What if there will be changes to the basic HIP operation e.g., based on 
the HIP BOF or otherwise?  (At least the flooding attack considerations 
are reletively new..)

The document, as an Informational RFC, could just cause more confusion
than clarity (what it's publication is probably intended to achieve) if
the HIP evolves somehow in the short term so that the document would need
to be updated.

Therefore, I'm concerned that publishing the document now might "end-run"  
the other work on HIP, and I'd certainly understand if the IESG (when
passed on to the review from the RFC Editor) would feel the same way..

<lurker mode=on>

-- 
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: [email-masked] (Pekka Nikander)
Date: Mon Oct 20 04:01:03 2003

> considered what is the intended outcome of this action?

Well, for one, the RFC Editor has explicitly asked for a
version of the HIP architecture document to be published,
even if it would go historic soon.

The second purpose is to create a stable starting point for
the proposed working group.  I am well aware that there are
lots of people who would like to get their pet peeve to HIP.
 From my point of view, even discussing such pet peeves would
be very premature and a completely waste of time at this point.
Basically, we need to keep the HIP protocol as simple as possible
for quite some time to be.  Hence, one purpose of publishing the
architecture document prior to creating the WG is to explicitly
avoid turf wars.

> certain that publishing the document at this phase is really reasonable.  

Did you read the draft?  The wording has changed somewhat; I have
explicitly tried to make it fairly open ended so that it is able
to incorporate changes to the actual protocol.  Furthermore, this
really is an architecture document, not the protocol document.

> the HIP BOF or otherwise?  (At least the flooding attack considerations 

Honestly, I don't see any changes that would affect the architecture.
In other words, if the architecture needs to be changed, that is
not HIP any more.

The actual protocol is a different issue.  And a separate draft.

> than clarity if the HIP evolves somehow in the short term so that
> the document would need to be updated.

Well, the architecure has been basically stable now for over two
years.  The last change of any significance was a clarification on
how to compute the checksums on regular data packets, and that
happened in San Francisco.  All the changes to the architecture
have been due to implementation experience -- there has been no
significant design issues in two or three years.  Hence, I don't
see how the formation of a WG would change the architecture so
suddenly.

--Pekka Nikander

---

From: [email-masked] (Pekka Savola)
Date: Mon Oct 20 04:25:01 2003

On Mon, 20 Oct 2003, Pekka Nikander wrote:
> The second purpose is to create a stable starting point for the proposed
> working group. [...] Hence, one purpose of publishing the architecture
> document prior to creating the WG is to explicitly avoid turf wars.

Agreed, as long as one realizes that blocking the work is a feature, 
not a bug.

> really is an architecture document, not the protocol document.

I glanced through it.  It seemed pretty good to me, I just had these 
concerns I mentioned.

> years.

I thought that e.g. the parts about allowing the IP address changes from
about everywhere (resulting in potential flooding attacks) to a stricter
model was changed rather recently?  Of course, I haven't been following 
the work too closely..

---

From: [email-masked] (Pekka Nikander)
Date: Mon Oct 20 05:09:01 2003

> Agreed, as long as one realizes that blocking the work is a feature, 

Sorry, but I don't understand your comment.  Do you mean the IESG
blocking a document?  Yes, I know it is a feature.  I did re-read
RFC2026 prior to sending the announcement of my plan to the list.
However, I also think that the RFC2026 wording more or less leaves the
IESG only two options:

  - either they must accept the publication of the document
    as Informational (perhaps with their warning statement), or

  - they must charter the new proposed WG so that it produces
    standards track documents.

The latter would not be very wise, IMHO.  (Of course, they can
decide not the charter the WG at all, and even block the BOF.
However, that might receive some pretty angry reactions...)

> model was changed rather recently?  

Well, yes and no.  Two years back people in general didn't understand
the dangers.  Hence, I would not consider that as an architectural
change.  But sure, there are details that have changed during the
last two years, and the last one (as far as I can remember) was the
change to the TCP/UDP pseudo-header handling.  The documents may have
been behind the general agreement among the implementors.

It is well possible that HIP contains other dangers (but flooding)
that we just don't know of now.  That is one more reason why the
WG has been proposed to be chartered to produce mainly Experimental
docs.  But, IMHO, it is not a reason not to publish the architecture
draft, as it is now.

--Pekka Nikander

---

From: [email-masked] (Pekka Savola)
Date: Mon Oct 20 05:14:01 2003

On Mon, 20 Oct 2003, Pekka Nikander wrote:
> blocking a document?  

No, I referred to the document blocking (more or less) *this* WG's output, 
or at least framing it.

[...]
> I also think that the RFC2026 wording more or less leaves the
> IESG only two options:
> 
[...]

(This is out of scope here, because I didn't phrase my concern properly
above, but..)

The latter is not accurate.  They can refer the document as *input* to 
the standards track publication process; it does not require that the 
documents themselves need to progress anywhere.