[My aplogies for sending this to three separage lists, but IMHO this is really relevant to all of them.] A have submitted a new I-D concerning a number of authorization issues in IPv6 related signalling, including Mobile IPv6 Binding Updates. The purpose of the I-D is to summarize and clarify the situation from this specific security point of view. As it has not appeared in the archieves yet, it is also available at http://www.nomadiclab.com/~pnr/publications/\ draft-nikander-ipng-address-ownership-00.txt I hope that the draft can act as one input to the the forthcoming Mobile IPv6 discussion to be held at Minneapolis, and clarify some issues related to using IPsec in IPv6 to protect various kinds of signalling messages. For your convenience, I've included the draft abstract below. --Pekka Nikander Abstract This document seeks to clarify a number of problems related to authorization of changing local routing information in the current IPv6 architecture. This document does not (currently) cover actual routing protocols. Instead, in IPv6, there are a number of additional mechanisms that allow local routing information to be changed. Some mechanisms are meant to be used only locally, while someof them allow changes to be initiated from a remote location; in the latter case, IPsec is used to protect the relevant signalling messages. However, the current specifications are partially obscure about the actual authorization requirements that must be met in order to be actually secure. The purpose of this document is to clarify the situation, and foster understanding of the potential attacks and required countermeasures. In this document, we first collect together and summarize the non-routing-protocol mechanisms that allow routing information to be changed. After that, we classify the mechanisms using a couple of orthogonal dimensions. Finally, we discuss the authorization requirements for the different mechanisms. It is important to note that the security problems discussed in this document become relevant only when we start to consider multiple security domains. As long as the mechanisms are used only within a single security domain, where all nodes are equally trusted, the problem does not exist. However, if several security domains are connected together, or if anything like "opportunistic IPsec", as promoted by John Gilmore, becomes reality, the problems discussed in this document will become very real. An other way of expressing the scope of the problems is to say that the attacks can be characterized as insider attacks. In general, the IPsec architecture, as it stands today, is relatively good in keeping outsiders out. However, it is currently not nearly as good at dealing with attacks from within. In a way, when IPsec is used to protect application level traffic, the applications are assumed to take care of their specific protection needs, e.g., in the form of user names, passwords, and application or operating system access control lists. Unfortunately, when IPsec is used to protect traffic signalling, as discussed in this document, the controls do not seem to be adequate. Basically, this is an authorization problem. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
