Steven Bellovin (IESG) writes: For a spec of this length, complexity, and security sensitivity, I'm remarkably happy with it. I have some issues, but I suspect that most can be resolved pretty easily. It was a delight to be able to delete some of my notes as I progressed through the document. Furthermore, given the length and complexity of the spec, I could easily be wrong about many of these points. I'd be delighted if that were the case. - 6.2.6 Should Mobility Data include the home address? The option doesn't seem to protect other data, including things like lifetime, sequence #, etc. - 10.3.1 Has the IPsec wg verified that K=1 really works? I'm not convinced of it, since some cookies are address-dependent. Beyond that, the SPD and the SADB will need to change as the source and destination IP addresses change. - 10.4.5 In the absence of ESP -- and why would it be omitted? -- how can the home agent reliably verify that the source address in the tunnel IP header is legitimate? I'd say that reverse- tunneled packets MUST be discard unless ESP-protected. (I'm astonished that it isn't even a SHOULD.) ----------------- Jari Arkko responds to IESG: And then some initial responses to some of the other issues raised by IESG: o Does K=1 work? IPsec WG has heard of the draft, but we haven't received more than a few comments. I agree that the cookies are dependent on addresses, but we tried to say in the spec that only the endpoints change, not the keys or cookies... maybe we should say that more clearly. o 6.2.7 and Mobility Data, and what it should protect: It does include sequence numbers etc, see "Mobility Header Data" which contains the full content of the MH. And then you had a very good question on whether the contents should cover home address as well. It turns out that this is unnecessary, because the key is dependent on the home address. So if someone changed the home address, Kbm would be different when recalculated by CN, and the MAC wouldn't verify. o Required ESP protection for reverse-tunneled traffic... hmm... not sure what to think of this. I think most people would like to avoid mandatory IPsec protection of tunnels. It is true that the address check provides only extremely limited protection. However, we have two cases: (a) Payload itself protected/w TLS, IPsec... then it does not matter if someone spoofs these. The receiver will not accept them anyway. (And we should do these things at the ends, not in the middle.) (b) Payload not protected. Since we do check the address, the attacker had to be able to forge source addresses. And if he is able to do this, he can spoof the mobile's traffic to the destination anyway, no need for the tunnel attack. Except in one special case... the traffic goes to the home network which might have had suitable filtering in place to prevent outsiders from claiming inside addresses. Perhaps we should add a statement about this to the security considerations and suggest that the payload protection be on in such cases? ----------------- Gabriel Montenegro responds to Jari Arkko: > And then some initial responses to some of the other issues > raised by IESG: > > o Does K=1 work? IPsec WG has heard of the draft, but we haven't received > more than a few comments. I agree that the cookies are dependent on > addresses, but we tried to say in the spec that only the endpoints > change, not the keys or cookies... maybe we should say that more > clearly. Some of this functionality was tested by ETSI, right? Perhaps not the k-bit itself, but the functionality behind it. So perhaps documenting that in the form of adding the proper ACK section in the ha-ipsec draft would be a good thing. > o 6.2.7 and Mobility Data, and what it should protect: It does include > sequence numbers etc, see "Mobility Header Data" which contains the > full content of the MH. And then you had a very good question on > whether the contents should cover home address as well. It turns > out that this is unnecessary, because the key is dependent on the > home address. So if someone changed the home address, Kbm would > be different when recalculated by CN, and the MAC wouldn't verify. check. > o Required ESP protection for reverse-tunneled traffic... hmm... not > sure what to think of this. I think most people would like to > avoid mandatory IPsec protection of tunnels. It is true that the > address check provides only extremely limited protection. However, > we have two cases: > (a) Payload itself protected/w TLS, IPsec... then it does not > matter if someone spoofs these. The receiver will not accept > them anyway. (And we should do these things at the ends, not in > the middle.) > (b) Payload not protected. Since we do check the address, the > attacker had to be able to forge source addresses. And if > he is able to do this, he can spoof the mobile's traffic > to the destination anyway, no need for the tunnel attack. > Except in one special case... the traffic goes to the > home network which might have had suitable filtering in > place to prevent outsiders from claiming inside addresses. > Perhaps we should add a statement about this to the > security considerations and suggest that the payload > protection be on in such cases? sounds good. ----------------- Jari Arkko responds to himself: > o Does K=1 work? IPsec WG has heard of the draft, but we haven't received > more than a few comments. I agree that the cookies are dependent on > addresses, but we tried to say in the spec that only the endpoints > change, not the keys or cookies... maybe we should say that more > clearly. Here's an update to this part. After a discussion with some IPsec folks the situation with the cookies is pretty interesting: See RFC 2408, Section 2.5.3 which states three rules for ISAKMP cookies: must depend on specific parties, can only be generated by the entity itself, and be fast. Then it goes on to recommends a particular way to do this, namely a hash of IP addresses. It seems that the three rules are satisfiable even with the K=1 option but the recommended method does not work directly. To satisfy the three rules, the "specific parties" must be treated as the original IP addresses, not the ones in use at the specific moment. Some implementations, but not all, do this. My understanding is that those implementations that have been modified to do NAT traversal will be capable of this. In conclusion this is something that deserves to be described better in the document but does not seem to be a fundamental technical problem; but some implementations might have to be changed in order to be able to work as home agent IKE. ----------------- Jari Arkko responds to Steven Bellovin: Steven, you've sent in a number of comments (thank you for that) over the course of the review. I've divided them in different issue as follows: * Issue 298 - The security related MIPv6 base comments (except IKE keyword) * Issue 282 - The IKE keyword issue * Issue 281 - Non-security related technical comments on base * Issue 294 - Your comments on ha-ipsec (related to Steve Kent's review) The issue discussions have been recorded at: http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html and the latest drafts can be accessed via: http://www.piuha.net/~jarkko/publications/mipv6/drafts/drafts.html The purpose of this e-mail is to propose final text modifications for issue #298. I've sent some e-mail previously on this, but this is the proposed text based on your input. Regarding the other issues: #282 We still owe you an explanation about the IKE keyword -- Vijay has written some text and I will soon incorporate it to the document and then we can discuss what the right keyword issue. #281 I believe has been addressed earlier. Finally, we are waiting to hear from you on #294 after we sent some clarifications regarding the home address option. But back to issue #298: > - 6.2.6 Should Mobility Data include the home address? The option > doesn't seem to protect other data, including things like > lifetime, sequence #, etc. As you may recall, our first response was the following explanation: "It does include sequence numbers etc, see "Mobility Header Data" which contains the full content of the MH. And then you had a very good question on whether the contents should cover home address as well. It turns out that this is unnecessary, because the key is dependent on the home address. So if someone changed the home address, Kbm would be different when recalculated by CN, and the MAC wouldn't verify." In order to make this clear in the document, I've added the following text to Section 6.2.6: "Note that while the contents of a potential Home Address destination option are not covered in this formula, the rules for the calculation of the Kbm do take the home address in account. This ensures that the MAC will be different for different home addresses." > - 10.3.1 Has the IPsec wg verified that K=1 really works? I'm not > convinced of it, since some cookies are address-dependent. > Beyond that, the SPD and the SADB will need to change as the > source and destination IP addresses change. The SPD and SADB do not need to change, as the communications use home addresses in a transparent fashion. However, what we say about K=1 and cookies is insufficient. Here's the new text in 10.3.1 that hopefully makes the treatment of the cookies clearer: "K = 1 Move the peer endpoint of the key management protocol connection, if any, to the new care-of address. For an IKE phase 1 connection, this means that any IKE packets sent to the peer are sent to this address, and packets from this address with the original ISAKMP cookies are accepted. Note that Section 2.5.3 in RFC 2408 Section 2.5.3 specifies rules that ISAKMP cookies must satisfy: they must depend on specific parties and they can only have been generated by the entity itself. Then it recommends a particular way to do this, namely a hash of IP addresses. With the K bit set to 1, the recommended implementation technique does not work directly. To satisfy the two rules, the specific parties must be treated as the original IP addresses, not the ones in use at the specific moment. I have talked to a few IKE implementors such as Tero (and myself) who confirm that for them the above treatment is not an issue and their code is already able to deal with this. However, not all IKE implementations have taken this into account -- basically those that haven't yet implemented NAT traversal can have problems. However, please remember that all this is needed only if the home agent explicitly states that it is capable of moving the IKE endpoints. This behaviour is optional. > - 10.4.5 In the absence of ESP -- and why would it be omitted? -- > how can the home agent reliably verify that the source address > in the tunnel IP header is legitimate? I'd say that reverse- > tunneled packets MUST be discard unless ESP-protected. (I'm > astonished that it isn't even a SHOULD.) You may remember our first response which was:"not sure what to think of this. I think most people would like to avoid mandatory IPsec protection of tunnels. It is true that the address check provides only extremely limited protection. However, we have two cases: (a) Payload itself protected/w TLS, IPsec... then it does not matter if someone spoofs these. The receiver will not accept them anyway. (And we should do these things at the ends, not in the middle.) (b) Payload not protected. Since we do check the address, the attacker had to be able to forge source addresses. And if he is able to do this, he can spoof the mobile's traffic to the destination anyway, no need for the tunnel attack. Except in one special case... the traffic goes to the home network which might have had suitable filtering in place to prevent outsiders from claiming inside addresses. Perhaps we should add a statement about this to the security considerations and suggest that the payload protection be on in such cases?" In order to make this clear, I've added the following text to the Security Considerations, Section 15.7: "Binding Updates to the home agents are secure. When receiving tunneled traffic the home agent verifies the outer IP address corresponds to the current location of the mobile node. This acts as a weak form of protection against spoofing packets that appear to come from the mobile node. This is particularly useful, if no end-to-end security is being applied between the mobile and correspondent nodes. The outer IP address check prevents attacks where the attacker is controlled by ingress filtering. It also prevents attacks when the attacker does not know the current care-of address of the mobile node. Attackers who know the care-of address and are not controlled by ingress filtering could still send traffic through the home agent. This includes attackers on the same local link as the mobile node is currently on. But such attackers could in any case send packets that appear to come from the mobile node, without attacking the tunnel; the attacker could simply send packets with the source address set to the mobile node's home address. However, this attack does not work if the final destination of the packet is in the home network, and some form of perimeter defense is being applied for packets sent to those destinations. In such cases it is recommended that either end-to-end security or additional tunnel protection is applied, as is usual in remote access situations." ----------------- ----------------- ----------------- -----------------