Subject: [MSEC] Re: comments on draft-ietf-msec-arch-00.txt

From: Brian Weis <[email-masked]>
Date: Fri, 25 Apr 2003 13:55:37 -0700

Hi Mark,

Thank you for your careful review. Please see replies inline.

Mark Baugher wrote:
> 
> Brian, Thomas
>    Here are my comments on
> http://www.ietf.org/internet-drafts/draft-ietf-msec-arch-00.txt.  Pardon my
> delay in getting to this.
> 
> Mark
> 
> 1. Document purpose and goals
>     o p.1 Abstract says it describes the protocols of the msec group.  I
> think it should be the overview and rationale of the msec architecture.

OK.

>     o We should remove msec wg references in the Abstract, Section 1.1,
> 5.2.2, 7 and any other places where it appears.  I believe that the IETF
> does not publish documents that reference working groups as a rule.  

Good point.

> [snip]                                                               In any
> case, I think we want to describe our architecture and contrast it with
> alternatives in the Introduction.

That's a good idea.

>     o We should remove the "work plan" aspects of this document, which is a
> legacy of the smug work where this document laid out what we were going to
> do.  Now, we need to describe something closer to a finished product, the
> msec architecture.
>       - the Abstract talks about "what must be addressed"

Good catch.

>       - 2.1 first sentence talks about a "proposed" framework and later has
> phrases like "attempts to incorporate" and "tries to express" which sounds
> more like an approach or proposal than a finished architecture (or set of
> protocols that perform a complete function).

OK.

>       - ditto on 3.0, which uses the phrase "begins to address" and 3.3
> says that multicast policy "will extend" the work done in the IPsec policy
> work and things that "need to be explored."

OK.

>       - ditto on 5.2.1, which mentions "functional building blocks" and
> 5.2.5 that speculates on what the work "must take into account."

OK.

>       - 7.0 has similar issues

My preference would be to get rid of section 7 completely. Comments?

>     o the WG needs to noodle a bit on what this document is.  It currently
> has a document roadmap, are we going to keep it and update the documents
> that it contains?

My preference would be to drop it completely from this document. Perhaps
a separate document akin to RFC 2411 would make sense to publish just
before MSEC disbands. Any document roapmap published before that time
would be incomplete.

> 2. The unfinished architecture
>     o 1.3 does not reference any policy documents and this is a gating
> factor to how far we can go in describing the msec architecture when this
> work is missing

I think section 1.3 does not belong in this document. References to
these documents should be made in the relevant sections later in the
document. Whether or not there are policy documents to cite (your
complaint) should be dealt with later policy sections.

>     o It's dicey to assume much about msec policy without having work
> underway on a policy I-D; if the GSAKMP Token is to serve as the basis of
> policy then we should reference that, but this is a work item that is neeed
> for the msec architecture to be complete.  right now, its vague when it
> comes to policy

There has been *some* work done one a policy arch I-D, but it hasn't
been completed yet. :-( I'm not sure where the GSAKMP Token fits into
the picture.

>     o 2.2.2 uses the phrase "allowed to" rather than "authorized to" and
> this is a place where we should discuss the authorization issues, much of
> which is sprinkled through the GSAKMP documents.

OK.

>     o I think we are at risk in publishing this document before we resolve
> our policy problem in msec since those who work on it may need to change
> the approach in ways that are not anticipated in the document

This whole document is built around the Reference Framework (figure 1).
This is so high level, I have trouble understanding how the policy work
would deviate from this high level.

> 3. Definitions
>     o I'm not sure exactly what is meant by "influence of policies" in
> 2.2.2.  "policy translation" is not defined in 3.3, nor is the term
> "mechanism."

I'll reword these things.

>     o "distributed" is not defined in terms of security in 2.2.1 or
> 2.2.4.  There are issues with authorization (e.g. delegation certs) and new
> protocols (e.g. among GCKS's and Policy Servers) and hard-to-solve
> problems, such as policy.

OK.

>     o 4.2 talks about the registration SA as being "crucial" and "protect
> other elements of the GSA (this is vague), but I think that the other two
> SAs can be established without the registration protocol per se.  Consider
> a smart card approach among others.

I think this section should be saying that there must be a registration
process in order to setup the other two SAs. Whether or not that's a
"registration protocol" or "installing a smart card" matters not. I'll
reword this.

>     o Section 5 incorrectly includes confidentiality and authentication
> between member and GCKS in the data plane services
>
> 4. Editorial comments
>     o 1.0 "...which have been developed which..."
>     o 2.1, the 1st three paragraphs could be condensed into several
> sentences I think
>     o 3.0 uses the phrase "emanating from the reference framework," which
> sounds stilted
>     o 3.0 uses "refreshment" where key management might be more appropriate
>     o The bullets are funky in 3.2 and throughout most of the document
>     o 3.3, the last sentence might better serve as the topic of the entire
> section
>     o 4.1 appears twice
>     o 4.1(2), first paragraph is redundant or belongs in sections 2 and 3
> or should somehow refer back to section 2 and 3
>     o "pairwise" might be a better word than "unicast" in most places
>     o p 13 "dta" should be "data"
>     o the normative terms "may" and "must" appear in section 5.2.1 and in
> other places of the document that are non-normative
>     o 5.2.3 is missing a comma after "paramount"
>     o 5.2.6 should have references for PDP and PEP

Thanks,
Brian

-- 
Brian Weis
Strategic Cryptographic Development, ITD, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

_______________________________________________
msec mailing list
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec