Re: Time shifitng/future redirection attacks

[Brian E Carpenter <brc@zurich.ibm.com>]

Kanchei,

Kanchei Loa wrote:
> 
> 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.
> 

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.

> 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.

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

> 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).

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

> 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.

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