Mohan Parthasarathy: I have a question on section 11.1 of draft-ietf-send-ndopt-00. 11.1 Threats to the Local Link Not Covered by SEND SEND does not compensate for an insecure link layer. In particular, there is no cryptographic binding in SEND between the link layer frame address and the IPv6 address. On an insecure link layer that allows nodes to spoof the link layer address of other nodes, an attacker could disrupt IP service by sending out a Neighbor Advertisement having the source address on the link layer frame of a victim, a valid CGA address and a valid signature corresponding to itself, and a Target Link-layer Address extension corresponding to the victim. The attacker could then proceed to cause a traffic stream to bombard the victim in a DoS attack. To protect against such attacks, link layer security MUST be used. An example of such for 802 type networks is port-based access control defined in the 802.1X standard [34]. I am not sure how link-layer security helps. 802.1x will not check the target link-layer address option. It checks only the source address of the mac header. And IP layer does not check the source mac address and only checks the target link layer option. So, how does link layer security help this case ? From what i can tell, the draft or current issues do not seem to answer the question. Unless you recommend the IP layer to cross check the source address of the mac header and the target link layer option AND you have 802.11i type security (that prevents mac address spoofing), this DoS attack cannot be prevented. But i remember some discussion in the past regarding why IP does not do the check. So, wihtout that, i don't see how this attack can be prevented. If my understanding is correct, the IP address ownership seems to solve the redirection attack problem i.e the attacker cannot redirect packets that are destined to some other address (that it does not own) to itself , but it still can cause flooding attacks by having the victim's mac address in the target link layer option of the NA. ----- Jari Arkko: In issue 24 we discussed this: http://users.piuha.net/jarkko/publications/send/issues/issue24.txt This brought us the text that follows the part that you quoted. The first part of Section 11.1 seems to say (more on this later) that the layer 2 - 3 binding is covered when both SEND and L2 security are used; the second part of Section 11.1 seems to imply otherwise. I think the bottom line is the following: o L2 security such as 802.11i can indeed ensure that the right sender uses the given MAC address. o The specific attack mentioned in the beginning of 11.1 is that the attacker lies both about the L2 and the ND target address. *This* attack is in fact prevented by the use of L2SEC + SEND. o However, there's another attack which is *not* prevented: the attacker lies just about the ND target address. Since neither L2 or SEND checks the L2 information against L3 information, there's currently nothing that prevents this attack. o We have discussed the prevention of this attack in SEND, but it would require stacks to retain the L2 addresses of the packets until the packets are processed by ND. Folks felt that this of a too tough requirement. So now I have a few questions: 1. Given the above, what change would you Mohan like to make to 11.1 to clarify it? 2. Is everyone still comfortable with the fact that no one is doing the L2-L3 cross check? ----- Hesham Soliman: > 2. Is everyone still comfortable with the fact that no > one is doing the L2-L3 cross check? Although this is probably not as bad as the reverse case (someone steals another node's address) it still allows an attacker to flood another node onlink. I don't think it's increadibly significant but are there implementations out there that cannot acquire the sender's MAC address from their link layer (802.anything) driver? In any case this seems like an optimisation that can be done on a per implementation basis, so I'm wondering whether we should say that SEND does not allow for the L2-L3 cross check because I don't see an inherent obstacle in SEND here, just implementation issues local to the IP stack and the driver. ----- Mathew Ford: While reading and thinking about this thread, a question occurred to me. Section 11.1 of draft-ietf-send-ndopt-00 states: For shared media, such as multiple nodes authenticated through the same 802.11 AP (which acts as a single port for all nodes), other measures [than 802.1x] are necessary [to prevent against specific attacks]... What 'other measures' are there, and would it be worth mentioning them explicitly in this section of the document? ----- James Kempf: >2. Is everyone still comfortable with the fact that no > one is doing the L2-L3 cross check? Might be worthwhile to mention it SHOULD be done in order to prevent the attack. ----- Mohan Prasarthy: > The first part of Section 11.1 seems to say (more on this later) > that the layer 2 - 3 binding is covered when both SEND and L2 security > are used; the second part of Section 11.1 seems to imply otherwise. Yeah. But the second part was not very clear. > I think the bottom line is the following: > > o L2 security such as 802.11i can indeed ensure that the right > sender uses the given MAC address. > > o The specific attack mentioned in the beginning of 11.1 > is that the attacker lies both about the L2 and the ND target > address. *This* attack is in fact prevented by the use of > L2SEC + SEND. So it only seemed that the text was inconsistent... > > o However, there's another attack which is *not* prevented: > the attacker lies just about the ND target address. > Since neither L2 or SEND checks the L2 information against > L3 information, there's currently nothing that prevents > this attack. Agreed. > 1. Given the above, what change would you Mohan like to > make to 11.1 to clarify it? > Yes, i am looking for a clarification. It would make it clear as to what SEND protects. > 2. Is everyone still comfortable with the fact that no > one is doing the L2-L3 cross check? I just re-read Pekka's summary on this issue. There were many reasons why it is not done. And Erik responded saying that in some cases it even provides flexibility like in bridging or even in some cases where there is no actual link-layer address. So, i am not sure how feasible this is. But it might be worth recommending. ----- James Kempf: I'm wondering now whether we should take out this paragraph and the next, and the last sentence in the previous paragraph. I don't believe the SEND spec should be making specific recommendations about how people should deploy 802.11 security. I think it should be sufficient to say what the first paragraph says, namely that SEND does not protect against attacks at the link layer - full stop - and leave it up to the link layer specification to say how the link layer is secured and how to deploy that security. We could add a sentence at the end of the first paragraph that says, in effect, consult the link layer specification for information about how to secure the link layer. ----- Michael Richardson: I believe that there are significant issues if we do not eventually work on ways to bind link layer security (1x) and network layer security (SEND). ----- Jari Arkko: I agree. But first some background on this issue. I think Michael is thinking about this based on the discussions we have had in the EAP mailing list. Michael presented an attack where someone offers WLAN access to clients. This offer is legitimate in the sense that this someone has a contract with a roaming group. But he is not providing the full service by himself. He simply attracks the customers, NATs their traffic, and sends it off to another WLAN service provider using his own flat fee account. The attacker then collects the roaming fees for a number of users, but leaves all bandwidth cost to the other provider. Anyway, one proposal is that if L2 security would provide the certs for SEND RAs, then we would have a tighter binding between what is happening at L2 and L3. Then an attempt to provide L3 services from someone else would be detected. However, we are still discussing whether this works. It would not prevent NATting, for instance, so it doesn't seem to fix the original attack. Anyway, I personally believe something like this will eventually be needed. So we should work on it... but I fear that it might take some time before we figure out what to do here. Maybe even IETF-IEEE etc discussions. (And it should not hold up SEND.) ----- James Kempf: > But first some background on this issue. I think Michael > is thinking about this based on the discussions we have had in > the EAP mailing list. Michael presented an attack where someone > offers WLAN access to clients. This offer is legitimate in the > sense that this someone has a contract with a roaming group. But > he is not providing the full service by himself. He simply > attracks the customers, NATs their traffic, and sends it off > to another WLAN service provider using his own flat fee > account. The attacker then collects the roaming fees for a > number of users, but leaves all bandwidth cost to the > other provider. I'm not sure I understand the attack. How would the other WLAN provider have to bear the bandwidth cost unless their AP was utilized? It sounds here like you are saying that the rogue has its own APs, right? If that is so, where is the problem with the bandwidth cost going to the other provider? > Anyway, one proposal is that if L2 security would provide > the certs for SEND RAs, then we would have a tighter > binding between what is happening at L2 and L3. Then > an attempt to provide L3 services from someone else > would be detected. However, we are still discussing > whether this works. It would not prevent NATting, > for instance, so it doesn't seem to fix the original > attack. Certs with L2 info on the router would allow this. > Anyway, I personally believe something like this > will eventually be needed. So we should work on it... > but I fear that it might take some time before we > figure out what to do here. Maybe even IETF-IEEE > etc discussions. (And it should not hold up SEND.) Yes. ----- Michael Richardson: > I'm not sure I understand the attack. How would the other WLAN > provider have to bear the bandwidth cost unless their AP was > utilized? It sounds here like you are saying that the rogue has > its own APs, right? If that is so, where is the problem with the > bandwidth cost going to the other provider? http://mail.frascone.com/pipermail/eap/2003-November/001936.html ----- Jari Arkko: > I'm not sure I understand the attack. How would the other WLAN provider have > to bear the bandwidth cost unless their AP was utilized? It sounds here like > you are saying that the rogue has its own APs, right? If that is so, where > is the problem with the bandwidth cost going to the other provider? The rogue provider has a node with two wireless interfaces: one to attrack clients, and another one to connect to the real provider's AP. The rogue provider has to pay for his node and the flat fee account, but the real provider pays all costs related to Internet connectivity. This would not fly as a business if you had to deploy the rogue nodes. But folks might put the required software in their laptops that they carry around anyway. This would also not fly if the cost of flat fee accounts is higher than what you can get as roaming fees. Anyway, we discussed this a bit further on the EAP WG mailing list and agreed with Michael that we need L2 to authenticate advertised access point properties, such as the SSID. (This currently *not* done.) We would also like to get a binding between L2 and L3, to ensure that the L3 services are provided by the same entity that we authenticated to. However, there are limits to what these two measures can achieve. The SSID authentication is useless if the user is not paying attention to the identifier, and the L3 service binding does not prevent someone from NATting the results to another L3 service. ----- Jari Arkko: My intention is to close this issue. I think we agree that there are issues if there is no L2 security and that there are issues if there is no L2 - L3 binding. In terms of our document, I think we agreed about the following: o Say that there is need for L2 security, as the current first paragraph in Section 11.1 does. o Add text to state that a binding between L2 and L3 would be desireable but that this document does not cover it. o Remove detailed discussion of IEEE 802 security specifications; this is not in our scope. Note that this changes the parts that we already agreed in issue 24. But I think the new text is better, as it still describes the issues but does not go into the details of specific link layers. I also downgraded the "MUST use link layer security" to a SHOULD. I think it would make sense to use SEND even if you did not have a secure link layer -- such as on an IETF wireless network -- and doing so should not violate the standards. Here's the new Section 11.1 text relating to this issue: SEND does not compensate for an insecure link layer. For instance, there is no assurance that payload packets actually come from the same peer that the Neighbor Discovery protocol was run against. SEND does not provide confidentiality for Neighbor Discovery communications. There may be no cryptographic binding in SEND between the link layer frame address and the IPv6 address. On an insecure link layer that allows nodes to spoof the link layer address of other nodes, an attacker could disrupt IP service by sending out a Neighbor Advertisement having the source address on the link layer frame of a victim, a valid CGA address and a valid signature corresponding to itself, and a Target Link-layer Address extension corresponding to the victim. The attacker could then proceed to cause a traffic stream to bombard the victim in a DoS attack. To protect against such attacks, link layer security SHOULD be used. Even on a secure link layer, SEND does not require that the addresses on the link layer and Neighbor Advertisements correspond to each other. However, it is RECOMMENDED that such checks be performed where this is possible on the given link layer technology. The modifications are also visible in http://www.piuha.net/~jarkko/publications/send/issues/issue33diff.html Comments appreciated. ----- James Kempf: Sounds fine. ----- Mohan Parthasarathy: > There may be no cryptographic binding in SEND between the link layer > frame address and the IPv6 address. On an insecure link layer that > allows nodes to spoof the link layer address of other nodes, an > attacker could disrupt IP service by sending out a Neighbor > Advertisement having the source address on the link layer frame of a > victim, a valid CGA address and a valid signature corresponding to > itself, and a Target Link-layer Address extension corresponding to > the victim. The attacker could then proceed to cause a traffic > stream to bombard the victim in a DoS attack. To protect against > such attacks, link layer security SHOULD be used. The last sentence is confusing. The bulk of the text above explains the attack. At last it says, the link layer security provides protection which is not completely correct. The following paragraph below explains what is needed to prevent the attack. So, i would suggest removing the last sentence above. Instead you can say something like "This attack cannot be prevented just by securing the link layer alone". Then the following paragraph seems like a good fit.. > Even on a secure link layer, SEND does not require that the addresses > on the link layer and Neighbor Advertisements correspond to each > other. However, it is RECOMMENDED that such checks be performed > where this is possible on the given link layer technology. ----- Jari Arkko: Right, thanks. -----