Subject: RE: Time shifitng/future redirection attacks

From: "Kanchei Loa" <[email-masked]>
Date: Thu, 1 Apr 2004 00:01:59 -0700

marcelo bagnulo wrote:

> I don't think that the decision is obvious but I think it is very
> importatn
> ti understand the additional vulnerabilities that we are
> introducing. It may
> be acceptable to introduce them, though.
>

I would like to point out that vulnerability is not always a bad thing as
portrayed so far. In many situation, it become a feature for the
application. For example, MiTM vulnerability has been the basis for NAT,
firewall, load balancing proxy server (traffic director), TCP proxy for
wireless subnet and many other so-called value-added network services. They
are very important network components that support the exponential growth of
Internet.

IMHO I suggest the architecture document should provide a balance view on
both security threats and value-added network services. In addition to the
list of security threats, we should also compile a list of value-added
network services. All proposals should be compared by not only the security
threats being eliminated or introduced but also the value-added service
being shutdown, added or refined. They are equally important issues for
deployment and operation.

For example, time shifting/future redirection attacks is a security threat
for "drive-by coffeshop" but it provides a very nice feature for the
"traffic director" whose job is to balance the load of the transport traffic
among a groups of servers. Based on the vulnerability of time
shifting/future redirection, the transport sessions could be sent from one
server to another with minimum efforts (the box doesn't need to be in the
middle of data path all the time).

My point is that the final decision of some security threats belongs to the
application. As the multi6 solution is at network/transport layer, we should
strive to be flexible in negotiating security mechanisms or lack of it. We
should learn the lesson from the deployment and operation of IPsec.

------------------------
Kanchei Loa
Email: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 01 Apr 2004 12:52:11 +0200

Kanchei,

> are very important network components that support the exponential growth of

I really don't want to start a flame-fest here, but the operational phrase
in your comment is "so called". It is precisely to get away from these
disruptive middleboxes that we want to deploy IPv6, and to get well architected
solutions to these problems from WGs such as midcom and opes. If we make
IPv6 MitM-proof we will have done a good thing, and that certainly applies
to multi6.

> deployment and operation.

Correct, but the question is not whether kludges will still work. The question
is whether multi6 is compatible with architectural approaches to these
problems.

> middle of data path all the time).

However, load balancing can be achieved in better ways than by blind
intervention at the transport level. 

> should learn the lesson from the deployment and operation of IPsec.

I agree for attacks (even MitM attacks) against the application layer. But there
may be MitM attacks that are directed at lower layers. It would be hard to explain
to the IESG that we chose to ignore those.

   Brian

---

From: "Kanchei Loa" <[email-masked]>
Date: Thu, 1 Apr 2004 13:17:16 -0700

Brian,

> to the IESG that we chose to ignore those.

Security is always a double edges sword.

I agree with you 100% on the "right way" to do networking and multi6
should be compatible with architectural approaches to these
problems, which is going to be part of future Internet. I also 
understand the sensitivity with IESG if we are perceived to be 
ignoring some attacks in our proposals.

I am not suggesting to ignore those attacks. But considering that 
we have been deploying equipments to do IP networking the 
"wrong" way" for last 15 years, the architecture documents 
should provide a balance view on those problems, such that the 
protocol designer would put knobs in their mechanisms to allow 
some security features being turn on/off by applications or 
operators, which would facilitate incremental deployment.

If we don't consider these knobs in the architecture, we might come 
out a super-secure multi6 solution then wondering why there 
is deployment and operation difficulty.

------------
Kanchei Loa
[email-masked]