Subject: RE: FW: I-D ACTION:draft-ietf-v6ops-ent-scenarios-03.txt

From: "Bound, Jim" <[email-masked]>
Date: Fri, 2 Jul 2004 01:38:18 -0400

My responses below. 

> 
> I did this on May 25, and Richard Graveman agreed.  A 
> suggestion was adding a paragraph like:
> 
>     Note that these kind of networks are uncommon and unfit to be a
>     model or example for deployment for enterprises in general.  
>     However, due to their importance to the vendor community, their
>     requirements should be considered explicitly.
> 
> As you see, I'm not arguing that the example needs to be 
> removed (though I wouldn't object :), but that it's made 
> crystal clear that the example might not be a basis for 
> *generalizing* how we would be deploying IPv6 in enterprises 
> because those security defence networks
> *are* uncommon, and they likely won't share much with 99% of 
> other enterprises (which aren't defence/military networks). 

The position of the design team and of many on this list is as follows:

I will just list a few users:

Military, Academic, and Security Surveillance networks today will deploy
IPv6 dominant networks on tactitical networks and treat IPv4 totally as
legacy operational protocol whereever possible.  In addition that is the
long term goal of IPv6 transition for any Enterprise.  This set of users
are very common and the scenario is highly fit to the kind of work that
must be done here in v6ops and required.

What I suggest as a compromise is as follows to the working group:

"Though this is a valid use case for the Enterprise Scenarios depicted,
at this time this scenario defines an early adopter of Enterprise
networks transitioning to IPv6 as a dominant protocol strategy (e.g.
IPv6 Routing, Applications, Security, and Operations), viewing IPv4 as
legacy operations immediately in the transition strategy, and not at
this time a predominant transition view to deploy IPv6 in the IETF
bodies knowledge base."

The reason these users do this are as follows:

IPv6 operational benefits required immediately.
Reduce Transition Cost.

> 
> Therefore, I'd not like to see a situation where someone 
> could point at the enterprise documents and say, "see, that's 
> how they did it, let's do so ourselves as well!" (even though 
> the actual scenarios and requirements would be entirely different).

The Scenarios do not do that and that is what the analysis is for and
where clarification should be made.

> 
> > I believe that this scenario is an interesting and 
> important scenario 
> > to explore.  How will people who are running highly secure/mobile 
> > networks today transition to IPv6?
> 
> If those networks have special characteristics applicable 
> only for military networks, let's just call them 
> transitioning in military networks, not highly secure (or 
> mobile) networks :). 

These are not just military networks.

> I see no problem having an example 
> describing military networks -- most countries have one, so 
> there should be some aggregation benefit here -- but it should
> (IMHO) be clearly separated from the other kinds of 
> enterprise examples.

I suggest the compromise above.

> 
> [...] 
> > At least within the U.S. Department of Defense there has been some 
> > resistance to deploying IPv6 on "operational" networks, because of 
> > uncertainty about the security implications of doing so.  
> It would be 
> > good for us to explore those implications, dispell any myths, and 
> > close any holes that do exist.
> 
> This is possibly beyond the scope of the enterprise 
> documents, but hopefully the issues will rise during the 
> process and they are written up and pushed forward (e.g., a 
> separate document about v6 myths or v6 security issues).

No one can discuss the details and I agree lets not pick on or discuss
any specific network user but their properties.  But as one who does
work with this user as SME the rationale is that IPv6 requires further
testing and integration with other components before it is put on a
mission critical production network where very bad results can happen
from a bug that could be military, medical, or intersection of a graph
for a mission critical decision.  So I want to clarify Margaret's
statement that it is not resistance and IPv6 is mandated and will
happen, but that more testing is required.  That testing is going on now
and one example is Moonv6 (there are others) www.mooonv6.org This same
rationale is being used by many Enterprises in the other scenarios too
and not just the user described above.  It is a smart approach and I
support it in industry as a note.  First step to transition in my view
is to set up pilots before switch to production.  This is true of any
network software or hardware upgrade to a production network.  

Regards,
/jim

> 
> -- 
> 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: Margaret Wasserman <[email-masked]>
Date: Fri, 2 Jul 2004 10:29:23 -0400

Hi Jim,

At 1:38 AM -0400 7/2/04, Bound, Jim wrote:
>  So I want to clarify Margaret's
>and one example is Moonv6 (there are others) www.mooonv6.org

Good clarification.

"Resistance" was a poor word choice, "caution" might have been better,
and I agree that caution is appropriate.

My thinking is that the v6ops group should be informed by early
operational experience with IPv6-only networks (like Moonv6) and that
during the analysis phase for the secure/defense networks scenario
we should consider if any IETF protocol or BCP-type work is needed to
resolve technical/protocol issues found  in that testing (if any).

The biggest issue with secure IPv6 deployment (as I understand it) is
not a lack of appropriate standards, but a lack of available, supported,
commercial products for information assurance that include good IPv6
integration (things like firewalls and intrusion detection systems).  So,
some of the issues may not be addressable by the IETF at all.  Have
things been getting better in this area?

Margaret