Subject: RE: filters and ACLs on identifiers? (was Re: other requirement?(wasRe: [RAM] Traffic Engineering

From: "Bound, Jim" <[email-masked]>
Date: Mon, 1 Jan 2007 09:54:51 -0500

> It's also important to note that the conflation of 
> encryption/ obfuscation with 'security' has in fact been 
> harmful by a) providing the incorrect impression that all one 
> has to do to secure one's host/ application/network is to 
> encrypt various random things, with no thought or effort 
> required apart from that, and b) encouraging the overuse of 
> encryption where it really isn't needed, with the net effect 
> that opsec personnel end up losing the ability to analyze and 
> filter undesirable network traffic.  So, we should work to 
> avoid promulgating a misimpression similar to that in which 
> some folks drew the incorrect inference that because of 
> 'mandated' IPSEC that IPv6 is magically 'secure'.

Exactly and I agree with the other input you have suggested on this long
set of mail threads over the Holidays :--).  That we must break the
architecture down to component layers and not complicate traffic
engineering as one example below.

>From Dobbins Roland
"It's somewhat easier for folks to understand, operate, and administer
endpoints with multiple logical network addresses which correspond with
multiple media (including varying flavors of wireless), or even on the
same media with logical partitioning a la VLANs, than a single interface
on the same physical network which carries multiple logical network
overlays.  Doing things like maintaining ACLs, firewall rules, and the
various traffic engineering tweaks which sparked this topic rapidly
becomes difficult, if not impossible."
End from Dobbins Roland

But I do think we need to discuss further the new routing layer not in
the context of endpoints, routers, or middle boxes for this new
architecture.  For example I think some of the conversation is missing
the advantage value proposition SHIM6 proposes for this new
architecture, and I believing if we are to deploy 5 years from now, we
must use our current work and evolve it.  Assuming SHIM6 adopts the new
transport model where only transport-identifiers are used by a new
transport that do not even use locators then SHIM6 in fact helps
multihoming as follows.  When the end node is notified through ICMPvX
that connection cannot be made it trys another transsport-identifier.
This reduces the routing entropy (and I agreed with Ran's definition) to
maintain routes to other Network Service Providers.  How the locators
are determined from the destination routing-namespace-identifier from
transport-namespace-identifiers as the packet is passed down the
implemented IP stack is conversation that will be required at some
point. Today I still believe an IPvX destination address is an
orthogonal discussion to the new transport model.  The node will have to
select the locators after the new transport model processing within the
IP stack and that should not be discussed in the context of the current
model if we are to evolve initially, and then we can back track to see
how we can transition current models.

Regarding routing intelligence on nodes lets not even go there right
now.  There will always be business case even for handhelds (e.g. radios
for military, first responders, Intelligent PDAs, data center access to
situational awareness feed, etc) to have knowledge of location at the
layer that determines next hop node.  That is a market and business
issue for implementation we should not assume a fixed set of notions
about who, what, why, or how implementations use the architecture for
now IMHO. 

> 
> [ Of course, one operator's undesirable network traffic is 
> another customer's BitTorrent, but that's a different 
> discussion for a different forum, heh. ]

Agree and that hopefully would be better defined with the new
architecture model.

Best,
/jim

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram