Wenxiao He writes: In ha-ipsec-03.txt BU/BA and Prefix Discovery packets are protected by two TRANSPORT mode SAs, while RR and payload packets are protected by maybe one IPSec TUNNEL mode SA. My questions is: If BU/BA and Prefix Discovery packets are also protected by an IPSec TUNNEL mode SA, is it possible that only one single IPSec tunnel SA is required for HA/MN singaling? Take section 5.2.1~5.2.4 for example, only one SA pair is required and all SPD on MN or HA should refer to this SA pair: mobile node SAD: - SA7(OUT, spi_g, home_agent_1, ESP, TUNNEL): source = home_address_1 & destination = any & proto = X - SA8(IN, spi_h, home_address_1, ESP, TUNNEL): source = any & destination = home_address_1 & proto = X home agent SAD: - SA8(OUT, spi_h, home_address_1, ESP, TUNNEL): source = any & destination = home_address_1 & proto = X - SA7(IN, spi_g, home_agent_1, ESP, TUNNEL): source = home_address_1 & destination = any & proto = X An example of MN->HA BU packet format is: IPv6 header (source = care-of address, destination = home agent) ESP header IPv6 header (source = home address, destination = home agent) Mobility header Binding Update Alternative Care-of Address option (care-of address) ----------------- Jari Arkko responds to Wenxiao He: What does X stand for in your description above? In the draft it stood for a particular payload protocol we wanted to protect, but I suspect you are using it more as a wildcard. Anyway, one problem related to the merging of the SPD entries is that the resulting SPD entry might match surprising packets. For instance, we'd have to use SA7 for Binding Updates sent to a correspondent node, because it uses the home address (in a HAO), its destination is irrelevant, and it falls to the set of protocol numbers which you'd like to protect. The current scheme does not have this problem, because the BU protection rule has the home agent's address in it ,and the RR protection rule has the tunnel interface in it. But when you merged these to get the single entry some details had to be lost, and as a consequence there are some new problems. There's been some discussion of single SA (pair) schemes on the list. Something like this could be developed in the future, but we'd need very specific rules and testing to make sure that we can actually pull it off. The current text requires support for the 4 SA (pair) scheme, but does not forbid the use of other schemes. I'm hoping someone will work more on these other schemes and try to see if they can be made to work. In the meantime, we should release the RFC... ----------------- Wenxiao He responds to Jari Arkko: > What does X stand for in your description above? In the > draft it stood for a particular payload protocol we wanted > to protect, but I suspect you are using it more as a > wildcard. Yes I used it as wildcard. I should have used "proto=any". > Anyway, one problem related to the merging of the SPD entries My intention is to merge SAD entries into one, not SPD entries. All SPD entries are still the same as in ha-ipsec-03.txt, with one difference that they all point to the same SAD entry. For example, the MN->HA BU SPD OUT is: mobile node SPD OUT: - IF source = home_address_1 & destination = home_agent_1 & proto = MH THEN USE SA7 <=== "change from THEN USE SA1". Same change applies to all remaining SPD entries. ----------------- Francis Dupont responds to Wenxiao He: > My intention is to merge SAD entries into one, not SPD entries. This has no interest as you should use IKE... ----------------- Wenxiao He responds to Francis Dupont: For manual keying all SPDs *share* the same SA by referreing to that SAD. Here's MN's SPD for BU: mobile node SPD OUT: - IF source = home_address_1 & destination = home_agent_1 & proto = MH THEN USE SA7 ( say, SA7 is the consolidated SA ) When it comes to IKE all SPDs should CREATE/"SHARE" the single SAD, too. Here's MN's SPD for BU: mobile node SPD OUT: - IF source = home_address_1 & destination = home_agent_1 & proto = MH THEN CREATE/SHARE ESP TUNNEL SA: gateway = home_address_1 & local phase 1 identity = user_1 ----------------- Jari Arkko responds to Wenxiao He: Ah, I see now better what you are suggesting. It looks pretty attractive, the minimization of the number of SAs is always useful, even if you use IKE. There may be a limited amount of places for SAs in the hardware, for instance. However, I have a few question marks and doubts: * Movements and care-of address change. In the current spec, the BU SAs are not moved, because the RHs and HAOs are added outside the IPsec encapsulation. Only the RR/payload protection SAs have to be moved. With the proposed change the following happens after the first movement from coa1 to coa2. In the initial state, the gateway of the outbound SA in the home agent is coa1. Now, a BU arrives from coa2 (which is fine). If the BU is successful, this SA is changed to use coa2, and this is used to carry the BA back to the mobile node. However, what if the BU fails for some reason? Currently, the IPsec processing of BAs is independent of the care-of addresses. With the proposed scheme we'd be temporarily using a care-of address X for the BU, and then go back to using the right address. Perhaps I'm missing something but I don't see a clean way to do this. * Its pretty new. Any other suprises? Will IKE be able to request these SAs in a way that the peer knows what is needed? I looked at this and the initial answer is yes, but... Anyway, I still think that we should keep the document as is at this stage even if this is an interesting suggestion. Unless someone's actually tried to this and found it working well, I'm scared to trust it. (But there's nothing that prevents the definition of this scheme as an extension or improvement of the current spec later.) ----------------- Gabriel Montenegro responds to Jari Arkko: Agreed. I'm also scared to trust it. Looks interesting to develop this afterwards, at which time other suggestions can be looked at as well (for example authz in mip), and get the most benefit out of revising the ha-mn-ipsec scheme. -----------------