Subject: Send protocol and CGA

From: Pekka Savola <[email-masked]>
Date: Sat, 8 Mar 2003 10:07:15 +0200 (EET)

Hello,

The send protocol spec is quite well written (a lot of comments in the 
queue in a separate mail), but there is one really imporant aspect I'd 
like the w.g. to consider.

That is, the base protocol and interactions with (encumbered) CGA.

Really, everything related to CGA must be thrown out of the base spec, and
placed in separate draft(s).  I thought this was the design decision early
on, has it changed or am I misunderstanding something?

My reasoning here is:
 - it is too difficult to read the protocol and assess its usability and 
completeness when CGA parts (which will *NOT* be used by some) are there

 - the base protocol is too closely interconnected to CGA parts (for 
instance check out the second bullet of section 10), and constitute a 
significant portion of already-long specification

 - securing ND is such an important issue, potentially affecting all 
nodes, that using encumbered technology is completely unacceptable.

 - when the organizations will be filing IPR disclosures, many of them are
likely to just give a blanket statement like "some portions of
ietf-send-ipsec-nn contain our IPR".  This makes it difficult to assess
whether *some other* portions (which are considered "free") of the spec
(e.g. trust anchors etc.) have IPR claims.

Therefore, I strongly request pulling CGA out of the spec before going any
further with it, and before those with claims on CGA make IPR disclosures
on it.

btw. which organizations had IPR claims on CGA?  I thought at least
Ericsson and Microsoft do, but only Microsoft has made IPR disclosure at
www.ietf.org/ipr/ (and has not made the disclosure on more recent
documents) -- if so, certainly a violation of the process.  Docomolabs
also has something on PBK, but not sure whether on CGA?  If I believed in
conspiracies, 3 out of 4 in the author list the employers of which have
significant vested interest in CGA-like mechanisms, would be sounding
alarm bells quite loudly.

-- 
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 from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: Jari Arkko <[email-masked]>
Date: Sat, 08 Mar 2003 11:25:48 +0200

Pekka,

Actually, this "co-conspirator" agrees to a large extent to
what you are saying. Namely, I do agree that we can't have
an IPv6 base component deployment prevented by patents. For
instance, it would be very unfortunate if we couldn't use this
in free operating system distributions.

However, at least Ericsson is in the process of preparing
an IPR and licensing statement relating to SEND. Hopefully
other companies will do the same. Let's wait and see what
the statements say, and decide then whether the IPRs are
an issue. If they are, we should do what you say. (And yes,
Ericsson has IPRs on CGAs. I don't think we have a specific
statement in the IPR page but we've had that statement
in the various earlier drafts.)

But at this point I'd like to ask you however about the
too-hard-to-analyze aspect. So this is a technical
problem, not just about the IPRs? How strongly do you feel
about that? Would that be helped by split of the document?
Or is there a need for some new "layering" or other abstraction
as well which would help the analysis? I'm not against smaller
documents. In fact, a protocol of this size at -00 is probably
going to be nearer 100 pages when fully baked... But there's
some additional overhead for lots of documents which the chairs
have tried to avoid, I think. Plus we have some bad experience
of badly split documents in the past. So there's something to
be said for self-contained single documents as well.

Jari

---

From: Pekka Savola <[email-masked]>
Date: Sat, 8 Mar 2003 15:48:09 +0200 (EET)

On Sat, 8 Mar 2003, Jari Arkko wrote:
> an issue. If they are, we should do what you say. 

I've seen a few licensing statements from Ericsson and I think those could
be truly reasonable at least to certain major parties.

However, looking back at the previous licensing statements from Microsoft, 
I can be about 99.9% certain that there will be no hope here.

(Unless, of course, one would work around the IPR somehow, but that seems 
unlikely too.)

> (And yes,

This is a violation of the process, but no harm is done (IMO), this has 
always been quite openly on the table.
 
> about that? Would that be helped by split of the document?

This is IMO mostly a technical problem if we assume that many would have
to implement SEND without CGA.

Of course, this mainly shift the "core" protocol to be more easily
verified, analyzed, implemented etc. -- while making it (at least
slightly) more difficult to add for thos who in fact do want to add CGA.

> as well which would help the analysis? 

That might help, yes, but I haven't thought about it enough to be 
able to say whether such a model would fix the corcerns.

Certainly, one could abstractify some language in specific sections to,
separate CGA and non-CGA to separate subsections, and analyze scenarios
where there are only-CGA, CGA + non-CGA, non-CGA (and maybe differences
which the router is), but as can be seen, this could become very complex.

So, splitting them apart seems like the best choice if one could expect 
CGA to be only an extension (albeit probably a very useful one).

> I'm not against smaller
> going to be nearer 100 pages when fully baked... 

Of course :-)

> But there's

I agree -- the main required functions should be in a single document (if
we look back on MIPv6 effort, one could say some functions could have been
separated from the start -- let's try not to add too many new features
here) -- but the question becomes "what is really required?".  I'd vager 
that describing the CGA and non-CGA semantics, analyzing the different 
cases where they're used or or, etc. would yield at least 20 additional 
pages in the document, and would make it much difficult to analyze the 
consequences (thus, a delayed product).

So, it seems to me that a single protocol, be it with CGA or without CGA, 
must be specified in one document if we want to manage the SEND case 
quickly.

(Another question altogether is whether we have sufficient pieces in place 
to support a SEND model without CGA...)

---

From: "James Kempf" <[email-masked]>
Date: Mon, 10 Mar 2003 09:26:49 -0800

Pekka,

IPR encumbered technology can be and has been incorporated into IETF standards.
An example is ROHC, the IPR within that draft is offered on a RAND basis. The
current IETF IPR rules are not like W3C in this regard, though there is a
working group discussing changes.

That said, as a general rule, standards which are IPR free are preferable to
those with IPR, and standards with free IPR (such as the Photuris, RFC 1822,
which was incorporated into IPsec) are preferable to RAND. Particularly with
something so basic as SEND, having RAND IPR is likely to cause the mechanism not
to be widely implemented, effectively making it useless.

PekkaN and I are currently working with Ericsson and Microsoft in order to get
CGAs released as free IPR for the purposes of SEND, to address the issue that
you mention. We expect the release, should it occur, to be similar to RFC 1822.
Please take some time to look at RFC 1822 and see if it meets your concerns. Of
course, these things take time and we do not expect a complete statement of
release by the SFO meeting.

If our efforts in this area should fail, we have a fallback position. The draft
currently discusses using host certificates for securing NA, and we would in the
event of failure remove CGAs leaving host certificates as the only mechanism.
From a technical standpoint, host certificates are an inferior mechanism because
they require provisioning of hosts with certificates, which is something that
nobody has quite managed to get to work yet. However, if we have to make that
the only mechanism, we will.

As far as we know (and participants in IETF work MUST disclose this information)
there is no other IPR on the draft.

Regarding your specific comments on the draft, we could probably do better in
describing how to use host certificates, currently, the draft is focussed on
CGAs because the DT believes they are a superior mechanism. We will clean that
up in the next round.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 10 Mar 2003 09:33:11 -0800

> I can be about 99.9% certain that there will be no hope here.

Microsoft has, in the past, released IPR for standards work. For example, they
released some IPR to W3C.

> must be specified in one document if we want to manage the SEND case

Agree.

> to support a SEND model without CGA...)

The DT has discussed the non-CGA case, but not as extensively. It needs more
attention.

            jak

---

From: Pekka Savola <[email-masked]>
Date: Tue, 11 Mar 2003 15:36:20 +0200 (EET)

> release by the SFO meeting.

A license similar to RFC1822 would seem sufficiently good to me, at least.  
Then, a CGA-only approach might be possible.

---

From: Alexandru Petrescu<[email-masked]>
Date: Wed, 12 Mar 2003 14:17:44 +0100

Jari Arkko wrote:
> However, at least Ericsson is in the process of preparing an IPR 
> and licensing statement relating to SEND. Hopefully other companies
>  will do the same.

Hi Jari, since this came up here, I reply here, but it is more
relevant to the IPR wg.

My personal hope is that I would like to see other companies spend as
much time selling the IETF ideas to their IPD as they spend in
selling their company's ideas to IETF.  Of course, that is an
internal activity that I can't really see, but from what I see at the
IETF public lists and in cooperative projects with other companies I
could easily deduce a striking difference.

Just two cents.

-- 
Message Classification: GBU