Re: IESG evaluation of draft-ietf-v6ops-mech-v2-02.txt

[Pekka Savola <pekkas@netcore.fi>]

Hi,

On Fri, 4 Jun 2004, Fred Templin wrote:
> Going back to a note from several weeks ago, I was wondering if there
> was any new status to report on the open issues for mech-v2-02. e.g.,
> are the authors maintaing an issue tracker page somewhere? Speaking
> of the authors, I was wondering if the second author (Bob Gilligan)
> has been active in the MECH(bis) effort, since it has been some time
> since I have seen any messages from him on the mailing lists.

Unfortunately, there is no issue tracker; the issues are described
briefly in the 3 week old mail.  The most issues are noted below.  
Additionally, there have been some clarifications on the ingress
filtering language.

The status is that we're in the process of doing two things:

 1) Discussing with Margaret on her requirement that the DNS ordering
text be removed, to be replaced with a normative reference to RFC3484,
blocking the move to Draft Standard. Erik and I disagree with that
approach, and are trying to convince her.

 2) Waiting for the submission of an informational document describing 
how to build secure IPsec v6-in-v4 tunnels.

I can send you an edited "working copy" off-list if you're interested;  
in any case, the draft will probably be posted on the list for short
review before moving forward.
 
> I am well aware that Bob has made significant past contributions
> that should be properly honored, but I was wondering what the
> policy is here? (I.e., will the MECH(bis) document be allowed
> to advance w/o Bob's active involvement?)

I'm not sure of the policy either, but for most documents, the old 
authors seem to be kept in even if they don't contribute.

Advancement will not be a problem; WG chairs and/or ADs can approve a 
document at RFC-editor's AUTH48 even if the authors don't respond.

> >(co-chair hat on)
> >
> >IESG has evaluated draft-ietf-v6ops-mech-v2-02.txt and the comments
> >are available at the I-D tracker, a direct link:  
> >https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1250&filename=draft-ietf-v6ops-mech-v2
> >
> >I'm collecting the most important ones here for feedback and opinions.  
> >I've followed up with most ADs for clarification, and I'm excluding
> >the trivial issues, misunderstandings, etc.
> >
> >Issues 1) and 2) are the most important ones, and I'd appreciate
> >comments from the WG on those at least.
> >
> >1) section 2.2 on DNS result ordering/filtering seems to be considered
> >inappropriately short, and it would be better to just refer to the
> >default address selection RFC3484. (Margaret Wasserman). Filtering is
> >inappropriate (Ted Hardie and Scott Hollenbeck).
> >
> >==> possibilities include at least:
> > a) keeping the current tense of specifying a "simple" address 
> >    selection, and referring to RFC3484 for more details, but reword 
> >    the text appropriately.  Remove filtering but keep ordering. It 
> >    might require some convincing to make the IESG accept this 
> >    approach.  (In other words, a simple dual-stack implementation would
> >    not necessarily have to implement RFC3484 to be 
> >    compliant/interoperable with this spec.)
> > b) remove most of the text, referring to RFC3484.  Note that RFC3484 
> >    is PS, and we could not advance to DS if we did that.  (In other 
> >    words, all the dual-stack implementations compliant with this spec 
> >    would also have to implement RFC3484.)
> >
> >2) the document appears to say, "just use IPsec", without giving 
> >sufficient details how to do it inappropriately. (Steve Bellovin)
> >
> >==> possibilities include at least:
> > a) adding some detail here how to set up the SA's
> > b) removing all the references to IPsec and hoping that security AD's 
> >    don't cry out.
> > c) defer to a future document to be written about the details of 
> >    secure v6-in-v4 tunneling; this has already started a month ago, 
> >    but hasn't produced a -00 draft yet.
> >
> >3) security considerations describing isolating different tunnels and
> >interfaces from each other seems to forbid the implementation
> >technique of point-to-multipoint (and more, multipoint-to-point)
> >tunnels. (Alex Zinin)
> >
> >==> this is intentional, as we removed automatic tunneling from the 
> >spec, but should probably be spelled out.  All the configured tunnels 
> >are expected to be point-to-point.
> >
> >4) the spec might consider whether the tunnel end-point is resolvable; 
> >if not, take the tunnel down. (Alex Zinin)
> >
> >==> I already agreed with Alex that this is a can full of worms, even 
> >if it's useful, and not something we should open here unless people 
> >insist. (The "resolvability" check is quite non-trivial when you have 
> >e.g., default or aggregate routes in your routing table.)
> >
> >5) the doc needs to mention dual-stack security considerations. 
> >(Jon Peterson)
> >
> >==> I already agreed with Jon that spelling these out here would be 
> >out of scope, and we'll just defer to another document, 
> >draft-savola-v6ops-security-overview-02.txt, for that (just like for 
> >3GPP analysis doc)
> >
> >
> >
> >
> >  
> >
> 
> 

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings