Catchin up with mail... But first, let me remind that the original text is raw. In security analysis you first try to find all holes, then try to plug them, and only finally estimate how real the remaining danger is. My text is still in the first phase, where paranoia is cranked up to maximum.
> -----Original Message----- > From: ext Thomas Narten [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 23, 2002 5:04 AM > To: Hippelainen Lassi (NET/Helsinki) > Cc: [EMAIL PROTECTED] > Subject: Re: Security considerations over RFC3041 (was: IPv6 w.g. Last > Call on "IPv6 for...) > > > [EMAIL PROTECTED] writes: > > > 2. Packet filtering > > > A stateless filter cannot test the lowest address bits, because > > being stateless it does not know which suffices are in use at any > > moment. > > What do you mean by a stateless filter? To avoid market bullsh!t, I classify firewalls and such things to three major groups: - Stateless filters examine each packet independently. Example: Access Control Lists. Stateless filters have static rules and are easy to scale to parallel clusters, but aren't sophisticated. - Stateful filters are aware of higher layer entities, like TCP sessions. Example: firewall with "Stateful Inspection". More effective, but far more difficult to run in clusters. - Content filters are in the application layer. Example: e-mail scanners. In this context a stateless filter is happily unaware of any dynamic changes in network topology, like new node addresses. > > Previously the stateless filter could limit subnet address > > scans effectively by passing only a very small set of > > suffices. After RFC3041 it will pass a scan of up to 2^64 > > addresses. If the scanned node connects using a slow PPP link > > (e.g. a 3GPP mobile node), the scan will block its link. > > I don't follow what you mean here. Could you please explain. If you know you have only 6 nodes in a subnet (e.g. a PAN), you can allocate a /125 mask and throw away all packets outside that range. But with RFC3041 the limit is /64. You can't even try to detect a random scan, because the range of possible addresses is so wide. An intrusion detector can't store each probed address for later analysis, because there are so many possible addresses. > > 3. The suffix as a covert channel > > Not sure this is a much of an issue personally. Seems like there are > more effective and less painful ways of compromising communication > channels. Possibly, but in paranoid mode you list the dangers first, and think about relevance only after the remedies have been identified. Anyway, not analysing a possible risk, because there are so many others around, doesn't sound wise... > > 4. Leaking the global identity > > > The new "random" addresses are created in a deterministic manner > > (RFC3041 3.2.1. "When Stable Storage Is Present"). The software > > vendor can therefore predict every future suffix used by the node, > > or identify the node as soon as one suffix has been detected. > > I don't follow this. Knowing the algorithm and knowing one point in > the sequence space isn't sufficient to predict future (or determine > past) values of the interface identifier. You also need to know some > other state information (e.g., the MAC address), which is not > generally available. Sorry for an ambiguous expression. That paragraph is a summary of the ones that follow. But you can't trust that your MAC remains secret. It has a structure and some published identifiers. As mentioned below, most of it can be guessed rather easily. > > The suffix sequence can be seeded using the Ethernet address *and* > > the serial number of the software licence, leaking even more > > identity information than what a single fixed address would. Both of > > these identifiers can be narrowed down to a rather small subset of > > the available namespace by guessing. The time when the node came > > on-line for the first time can be used as guidance. > > Again, knowing one point in the sequence of random numbers is not > enough to figure out what previous or fugute values will be. Also 3041 > says nothing about using software licence number to seed the sequence. The RFC may not mention software serial numbers, but they aren't prohibited either. They can't be. The stack vendor can use any parameters and algorithm that seem useful, without most of the users noticing anything strange. In this case the threat model is a vendor that wants to track customers, with the lame excuse of detecting pirated copies. > > If the suffix is generated using MD5 as suggested in RFC3041, an > > ephemeral identity can be recovered by anyone, by brute forcing the > > missing 64 bits of initial state from two consecutive suffices. The > > processing expense is not prohibitively high, and is getting lower > > all the time. This works also in the "absence of stable storage" > > mode. > > It's prohibitive enough that folks won't bother to do this on a > massive scale (i.e., for lots of addresses). That seems good enough > for the purposes defined in the 3041. > > Thomas Again, the reality check isn't included in the fragment... Anyway, the knee-jerk reaction of the cryptologic tribe would be to recommend SHA-1 rather than MD5. RFC3041 publishes 64 bits of the internal state. With MD5 that leaves only 64 bits secret, and that isn't secure anymore. Current security erosion rate being one bit per year, 64 bits becomes crackable with home computers before IPv6 has taken over from IPv4. With SHA-1 you would have 96 bits of remaining secret. -- Lassi -------------------------------------------------------------------- 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] --------------------------------------------------------------------
