Bernard Aboba writes: Section 3.2 Presumably the CoA is required as the Source Address for the HOTI message with no Home Address Option (HAO) since if HOTI/HOT is sent after movement, no binding cache entry exists binding the CoA to the HoA. However, it also seems possible for the HOTI/HOT messsage to be sent *before* movement (this gets HOTI/HOT out of the critical path), in which case a valid binding cache entry might exist. Is there another reason that the HAO is precluded? I mention this because it appears that the RR messages are the only ones in Section 3 that do not include a HAO or RH Type 2. In Section 7 it says: "One of the main reasons for choosing such a format is that it removes the overhead of twenty four bytes when a home address option or routing header is added to the tunneled packet". Would it be possible to add some text clarifying this? Section 3.2 "The home agent accepts packets sent like this, as the outer source address in tunnel packets is not checked". You might cite Section 5.1.2.1 of RFC 2401: "NOTE: In principle, the encapsulating IP source address can be any of the encapsulator's interface addresses or even an address different from any of the encapsulator's IP addresses, (e.g., if it's acting as a NAT box) so long as the address is reachable through the encapsulator from the environment into which the packet is sent. This does not cause a problem because IPsec does not currently have any INBOUND processing requirement that involves the Source Address of the encapsulating IP header. So while the receiving tunnel endpoint looks at the Destination Address in the encapsulating IP header, it only looks at the Source Address in the inner (encapsulated) IP header." Steve Kent describes some of the security issues arising from this in the following post: [AuthSource] Kent, S., "Authenticated Source Addresses", IPsec WG Archive ( ftp://ftp.ans.net/pub/archive/IPsec ), Message-Id: , January 5, 1996. Section 4.2 "When IPsec is used to protect return routability signaling or payload packets, the security policy database entries SHOULD be defined specifically for the tunnel interface between the mobile node and the home agent. That is, the policy entries are not generally applied on all traffic on the physical interface of the nodes but rather only on the traffic that enters this tunnel." Maybe I'm not understanding what you mean here, but this looks to me like special case IPsec processing. My understanding is that the processing described above is somewhat more akin to what occurs with transport mode IP-IP encapsulation than with tunnel mode. See the following draft for more details: http://www.ietf.org/internet-drafts/draft-touch-ipsec-vpn-04.txt Note also that in various places in the document, tunnel mode is required in preference to transport mode IP-IP, even where manual keying is used. Since the two are identical on the wire (the difference is in how they are negotiated within IKE), I am not sure how such a preference can be enforced. Section 4.2 "In order to do this, the security policy database entries MUST unequivocally identify a single security association for any given home address and home agent when manual keying is used." This seems to contradict Section 5, which seems to imply that multiple SAs will exist between the MN and HA. Can you clarify? Section 4.3 "Tunnel mode IPsec ESP MUST be supported and SHOULD be used for protection of packets belong to the return routability procedure" Since this is only a SHOULD, is there an alternative? Does it matter whether dynamic or manual keying is used? Section 4.4 "Therefore if preshared secret authentication is used in IKEv1 between the mobile node and the home agent then aggressive mode MUST be used." This says that it is not possible to use IKEv1 Main Mode with pre-shared keys alongside MIPv6. This by itself is not all that surprising since the difficulties with use of Main Mode/pre-shared keys along with dynamic IP addresses are well known. But what is unique here is that the difficulties occur even when the home address is static. That is, SAs such as the tunnel mode RR SA are set up from the CoA, which is dynamic, without an HAO. This means that even if the HoA is static, that IKE MM cannot be used with pre-shared keys. The problem is fixed in IKEv2, but since some implementors will no doubt try to integrate IKEv1 with MIPv6, some additional explanation is required in places, I think. At a minimum, I'd like to understand why the HOTI/HOT messages can't have an HAO even if HOTI/HOT is done prior to movement. Section 4.4 "Conversely, the IPsec security associations with the mobile node's home agent MUST be requested from the key management protocol with the home address as the mobile node's address." One could read this as contradicting the previous paragraph. What I think you mean here is that IDci = HoA in Quick Mode. ------------------------------ Erik Nordmark responds to Bernard Aboba: Some background info. The HOTI messages are reverse tunneled through the HA with an outer source address = CoA and an inner source address = HoA. The MN needs to send a binding update to the HA before it can send HOTI messages to correspondents so that the HA can check the HoA/CoA relationship in the reverse tunneled packets. (If HOTI was sent with CoA as the source the response=HOT would go directly to the CoA i.e. it would fail to test that the MN is indeed reachable at its Home Address.) > At a minimum, I'd like to understand why the HOTI/HOT messages can't > have an HAO even if HOTI/HOT is done prior to movement. A HAO on the HOTI would cause the CN to reject the HOTI after movement since the HoA/CoA wouldn't match the binding cache on the CN. ------------------------------ Bernard Aboba responds to Erik Nordmark: Since the HA decapsulates the tunneled HOTI message from the MN, it reaches the CN with source address = HoA. This is true regardless of the outer source address of the packet tunneled to the HA by the MN; the presence of a HAO in the outer IP header makes no difference. Regardless, the HOT message sent by the CN has destination address = HoA; as a result, the packet is received by the HA. The proof of reachability is that the HA routes the HOT to the MN by some means. The outer destination address of the HOT sent by the HA to the MN = CoA because that is the only way for the HA to reach the MN when it is not at home; whether the HOT is encapsulated in an IP packet with inner destination address = HoA or instead, a RH Type 2 header is used doesn't make a difference. So it seems like the reachability test is met either way, no? > > At a minimum, I'd like to understand why the HOTI/HOT messages can't > > have an HAO even if HOTI/HOT is done prior to movement. > > A HAO on the HOTI would cause the CN to reject the HOTI after movement > since the HoA/CoA wouldn't match the binding cache on the CN. Since the HAO is only on the outer IP header which is decapsulated by the HA, the CN never sees this; it only sees the contents of the decapsulated HOTI message and the COTI as well. So the HOTI would not be rejected by the CN. I think the issue is actually more related to the checks done by the HA on the HOTI/HOT and COTI/COT messages. As you said, the MN-HA BU must be done first to create the binding cache entry. However in looking through both this draft and draft-ietf-mobileip-ipv6-21.txt I am not finding a section describing the checks done by the HA. For example, these checks are not described in Section 8.4. Note that Section 11.6.1 of the MIPv6 draft indicates that a HOT tokens MAY be reused, so that HOTI/HOT messages don't need to be sent after every move. ------------------------------ Jari Arkko responds to Bernard Aboba: > Section 3.2 > > Presumably the CoA is required as the Source Address for the HOTI message > with no Home Address Option (HAO) since if HOTI/HOT is sent after > movement, no binding cache entry exists binding the CoA to the HoA. > However, it also seems possible for the HOTI/HOT messsage to be sent > *before* movement (this gets HOTI/HOT out of the critical path), in which > case a valid binding cache entry might exist. Is there another reason that the HAO is > precluded? I mention this because it appears that the RR messages are the only > ones in Section 3 that do not include a HAO or RH Type 2. Actually, its both the RR messages and the payload messages. The main issue is therefore the encapsulation format for IP traffic tunneled through the home agent. The working group has debated the issue at length. Basically, there were two alternatives: 1. Tunnel encapsulation uses care-of addresses as the source / destination. This is the current approach. 2. Tunnel encapsulation uses home addresses (i.e. care-of address as the source plus a HAO). This was the other alternative. This consumes additional bytes for carrying the HAO packet, which is bad. On the other hand, it would have been a nice format in the sense that all the IPsec SAs could have been based on the home addresses, and the upon movement we would not have been forced to update the destination gw address for the outgoing SA at the home agent side. > In Section 7 it says: > > "One of the main reasons for choosing such a format is that it removes the > overhead of twenty four bytes when a home address option or routing header > is added to the tunneled packet". > > Would it be possible to add some text clarifying this? This is the same thing as above. > Section 3.2 > > "The home agent accepts packets sent like this, as the outer source > address in tunnel packets is not checked". > > You might cite Section 5.1.2.1 of RFC 2401: > > "NOTE: In principle, the encapsulating IP source address can > be any of the encapsulator's interface addresses or even an > address different from any of the encapsulator's IP > addresses, (e.g., if it's acting as a NAT box) so long as the > address is reachable through the encapsulator from the > environment into which the packet is sent. This does not > cause a problem because IPsec does not currently have any > INBOUND processing requirement that involves the Source > Address of the encapsulating IP header. So while the > receiving tunnel endpoint looks at the Destination Address in > the encapsulating IP header, it only looks at the Source > Address in the inner (encapsulated) IP header." Yes. Thanks. > Steve Kent describes some of the security issues arising from this in the > following post: > > [AuthSource] > Kent, S., "Authenticated Source Addresses", IPsec WG Archive ( > ftp://ftp.ans.net/pub/archive/IPs ec ), Message-Id: > , January 5, 1996. On a quick read I *think* Steve talks about the inner address checks; his problem is that if the inner addresses are not checked then someone receiving the final packet may be fooled. It seems to me that as far as the outer addresses are concerned, the cryptographic proof (i.e. valid MAC) is far more important than the source address. In the inner addresses the issue is very different, because the final recipient of the packet does not have cryptographic validation. > Section 4.2 > > "When IPsec is used to protect return routability signaling or payload > packets, the security policy database entries SHOULD be defined > specifically for the tunnel interface between the mobile node and the > home agent. That is, the policy entries are not generally applied on > all traffic on the physical interface of the nodes but rather only > on the traffic that enters this tunnel." > > Maybe I'm not understanding what you mean here, but this looks to me like > special case IPsec processing. My understanding is that the processing > described above is somewhat more akin to what occurs with transport mode > IP-IP encapsulation than with tunnel mode. See the following draft for more details: > > http://www.ietf.org/internet-drafts/draft-touch-ipsec-vpn-04.txt Ok. I need to read this. > Note also that in various places in the document, tunnel mode is required > in preference to transport mode IP-IP, even where manual keying is used. > Since the two are identical on the wire (the difference is in how they are > negotiated within IKE), I am not sure how such a preference can be > enforced. Ok, I agree. Need to think about how to formulate this in a better way. > Section 4.2 > > "In order to do this, the security policy database entries MUST > unequivocally identify a single security association for any given home > address and home agent when manual keying is used." > > This seems to contradict Section 5, which seems to imply that multiple SAs > will exist between the MN and HA. Can you clarify? Ah yes. Obviously the issue is that there might be multiple purposes (e.g. MH vs. something else). So just src/dst will not give you a unique tunnel. I will work on better text for this. > Section 4.3 > > "Tunnel mode IPsec ESP MUST be supported and SHOULD be used for protection > of packets belong to the return routability procedure" > > Since this is only a SHOULD, is there an alternative? Does it matter > whether dynamic or manual keying is used? No, but the question is whether this protection is turned on. Ok, I'll clarify this too. > Section 4.4 > > "Therefore if preshared secret authentication is used in IKEv1 between the > mobile node and the home agent then aggressive mode MUST be used." > > This says that it is not possible to use IKEv1 Main Mode with pre-shared > keys alongside MIPv6. This by itself is not all that surprising since the > difficulties with use of Main Mode/pre-shared keys along with dynamic IP > addresses are well known. But what is unique here is that the difficulties > occur even when the home address is static. That is, SAs such as the > tunnel mode RR SA are set up from the CoA, which is dynamic, without an HAO. > This means that even if the HoA is static, that IKE MM cannot be > used with pre-shared keys. The problem is fixed in IKEv2, but since some > implementors will no doubt try to integrate IKEv1 with MIPv6, some > additional explanation is required in places, I think. At a minimum, I'd Ok. > like to understand why the HOTI/HOT messages can't have an HAO even if > HOTI/HOT is done prior to movement. Discussed above, assuming I understood your question correctly. > Section 4.4 > > "Conversely, the IPsec security associations with the mobile node's home > agent MUST be requested from the key management protocol with the home > address as the mobile node's address." > > One could read this as contradicting the previous paragraph. What I think > you mean here is that IDci = HoA in Quick Mode. THat's right. Needs better text. ------------------------------ Bernard Aboba responds to Jari Arkko: > 1. Tunnel encapsulation uses care-of addresses as the source / destination. > This is the current approach. > > 2. Tunnel encapsulation uses home addresses (i.e. care-of address as > the source plus a HAO). This was the other alternative. This > consumes additional bytes for carrying the HAO packet, which is > bad. On the other hand, it would have been a nice format in the > sense that all the IPsec SAs could have been based on the home > addresses, and the upon movement we would not have been forced > to update the destination gw address for the outgoing SA at the > home agent side. OK. That's what I thought the draft was saying, but I wasn't sure. It might be worth laying out these choices, and also their implications -- that Main Mode with pre-shared keys can't be used with IKEv1, even if the Home Address is static. ------------------------------ Erik Nordmark responds to Bernard Aboba: > Since the HA decapsulates the tunneled HOTI message from the MN, it > reaches the CN with source address = HoA. This is true regardless of the > outer source address of the packet tunneled to the HA by the MN; the > presence of a HAO in the outer IP header makes no difference. I erronously assumed you wanted to put in on the inner header. HOA doesn't cause a problem on the outer header. > The outer destination address of > the HOT sent by the HA to the MN = CoA because that is the only way for > the HA to reach the MN when it is not at home; whether the HOT is > encapsulated in an IP packet with inner destination address = HoA or > instead, a RH Type 2 header is used doesn't make a difference. The problem for this part is that the HA forwarding the packet can't add an RH type 2 to a packet originated by somebody else - if nothing else it messes up path MTU discovery since the packet too big messages would go to the source = CN which has no idea that the HA made the packets bigger. Thus from HA to MN encapsulating is the only working scheme. Of course, when encapsulating the HA could include an RH as part of the outer headers, but I don't know what problem that solves. ------------------------------ Bernard Aboba responds to Jari Arkko: > Actually, its both the RR messages and the payload messages. The main issue > is therefore the encapsulation format for IP traffic tunneled through the > home agent. Ah, this is the real issue, isn't it. Putting a HAO on the tunneled HOTI/HOT packets isn't a big deal, but putting it on *data* is an issue for realtime traffic. If *all* the IPsec SAs don't originate from the HoA, then nothing is gained. Still, this is probably grounds for a SHOULD but maybe not a MUST (particularly given some security implications). > to update the destination gw address for the outgoing SA at the > home agent side. RR security is weaker than that provided by IKE, so that movement is potentially a weak link enabling the movement of IPsec SAs under the guidance of an attacker. It would be different if the RRs were cryptographically protected, since then we could require that this level of protection (e.g. RSA key size) were equivalent to that used in IKE. At a minimum, I think it's probably a sensible thing to provide advice about restricting the scope of APIs provided to manipulate the MN-HA SAs. For example, one could require that: a. The APIs only work when referring to SAs affected by a previously received binding update b. Only cover the SAs described in your document (transport mode MH coverage, tunneling HOT/HOTI, etc.) ------------------------------ Jari Arkko responds to Bernard Aboba: > Ah, this is the real issue, isn't it. Putting a HAO on the tunneled > HOTI/HOT packets isn't a big deal, but putting it on *data* is an issue > for realtime traffic. Right. > If *all* the IPsec SAs don't originate > from the HoA, then nothing is gained. Still, this is probably grounds for > a SHOULD but maybe not a MUST (particularly given some security > implications). Yes, but if you look at the way the requirement in 3.2 is formulated it says that you MUST _support_ this particular set of headers. The intention is that folks are free to support other encodings as well. Would this be sufficient to you? >> to update the destination gw address for the outgoing SA at the >> home agent side. > > > RR security is weaker than that provided by IKE, so that movement is > potentially a weak link enabling the movement of IPsec SAs under the > guidance of an attacker. It would be different if the RRs were > cryptographically protected, since then we could require that this level > of protection (e.g. RSA key size) were equivalent to that used in IKE. > > At a minimum, I think it's probably a sensible thing to provide advice > about restricting the scope of APIs provided to manipulate the MN-HA SAs. > For example, one could require that: > > a. The APIs only work when referring to SAs affected by a previously received > binding update > b. Only cover the SAs described in your document (transport mode MH > coverage, tunneling HOT/HOTI, etc.) Something like this could be good yes. One thing to note is that the IKE-MIPv6 API is *only* for the home agent case. And all location updates by the home agent are due to cryptographically protected Binding Updates. So I don't think RR security level will make IPsec SAs vulnerable to attacks. But yes, this probably deserves to be explained in the document ;-) ------------------------------ Jari Arkko writes: Here's an initial text proposal to address the issues raised by Bernard: 1. Care-of address source vs. use of HAO. Here I added first a new paragraph to Section 3.2: "Note that there are tradeoffs in using care-of addresses as the gateway addresses versus using the home address and attaching an additional Home Address destination option and/or Routing header to the packets. The basis for requiring support for at least the care-of address case has been discussed in Section 7." And then in Section 7 the first paragraph has been expanded into the following text: "We have chosen to require an encapsulation format for return routability and payload packet protection which can only be realized if the destination of the IPsec packets sent from the home agent can be changed as the mobile node moves. One of the main reasons for choosing such a format is that it removes the overhead of twenty four bytes when a home address option or routing header is added to the tunneled packet. Such an overhead would not be significant for the protection of the return routability packets, but would create an additional overhead if IPsec is used to protect the tunneling of payload packets to the home agent. This overhead may be significant for real-time traffic. Given that the use of the shorter packet formats for any traffic requires the existence of suitable APIs, we have chosen to use the shorter packet formats also for the protection of the return routability packets. (Note that packet formats and header ordering discussed in Section 3 must be supported, but implementations may also support other formats. Some implementations may therefore also support the protection of payload packets using the home address as the gateway address.) In order to support the care-of address as the gateway address on the mobile node side, the home agent must act as if the gateway address of a security association to the mobile node would have changed upon movements. Implementations are free to choose any particular method to make this change, such as using an API to the IPsec implementation to change the parameters of the security association, removing the security association and installing a new one, or modification of the packet after it has gone through IPsec processing. The only requirement is that after registering a new binding at the home agent, the next IPsec packets sent on this security association will be addressed to the new care-of address." 2. The API and where it should be used. Here I added the following text to the end of Section 4.3: "Such gateway address changes can be implemented, for instance, through an API from the Mobile IPv6 implementation to the IPsec implementation. It should be noted that the use of such an API and the gateway address changes MUST only be done based on the Binding Updates received by the home agent and protected by the use of IPsec. Address modifications based on other sources, such as Binding Updates to the correspondent nodes protected by return routability, or open access to an API from any application may result in security vulnerabilities." 3. Tunnel source address discussion. I added the following to Section 3.2: "For a discussion of the role of source addresses in outer tunnel headers, see Section 5.1.2.1 of [RFC 2401]. Note also that the home agent requires the packets to be authenticated regardless of the source address change, hence the "new" sender must possess the same keys for the security association as the it had in the previous location. This proves that the sender is the same entity, regardless of the changes in the addresses." 4. Section 4.2 and single vs. multiple SAs and the "unequivocal" requirement. I simply added "to protect the Binding Updates" in the following text: "In order to do this, the security policy database entries MUST unequivocally identify a single security association for protecting Binding Updates between any given home address and home agent when manual keying is used. When dynamic keying is used, the security policy database entries MUST unequivocally identify the IKE phase 1 credentials which can be used to authorize the creation of security associations for protecting Binding Updates for a particular home address." 5. The SHOULD for RR tunnel mode protection and whether there's an alternative. I added the following note to Section 1: "Note that where this document indicates a feature MUST be supported and SHOULD be used, this implies that all implementations must be capable of using the specified feature, but there may be cases where, for instance, a configuration option disables to use of the feature in a particular situation." 6. Main-mode preshared secret IKEv1 difficulties even when the home address is static. I added this to Section 4.4: "Note that the difficulties with main mode and preshared secrets in IKE version 1 are well known for dynamic addresses. With static addresses, there has not been a problem. With Mobile IPv6, however, the use of the care-of addresses to run IKE towards the home agent presents a problem even when the home address stays stable." 7. Section 4.4 and IDci = HoA in Quick Mode. Here I reformulated the text to the following: "However, the IPsec security associations with the mobile node's home agent use home addresses. That is, the IPsec security associations MUST be requested from the key management protocol using the home address of the mobile node as the client identity." 8. IP-in-IP vs. tunnel mode. Still working on this. These changes are also on the web at http://www.piuha.net/~jarkko/publications/mipv6/drafts/mipv6haipsec.txt http://www.piuha.net/~jarkko/publications/mipv6/drafts/mipv6haipsec.html http://www.piuha.net/~jarkko/publications/mipv6/drafts/mipv6haipsecdiff.html Bernard's comments have been filed as issue #284 at http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html ------------------------------ Bernard Aboba responds to Jari Arkko: Thanks. This looks good. Some comments: > "We have chosen to require an encapsulation format for return > routability and payload packet protection which can only be > realized if the destination of the IPsec packets sent from the > home agent can be changed as the mobile node moves. One of the > main reasons for choosing such a format is that it removes the > overhead of twenty four bytes when a home address option or > routing header is added to the tunneled packet. Such an overhead > would not be significant for the protection of the return > routability packets, but would create an additional overhead if > IPsec is used to protect the tunneling of payload packets to the > home agent. This overhead may be significant for real-time > traffic. Given that the use of the shorter packet formats for > any traffic requires the existence of suitable APIs, we have > chosen to use the shorter packet formats also for the protection "use" -> "require support for" >> of the return routability packets. (Note that packet formats >> and header ordering discussed in Section 3 must be supported, >> but implementations may also support other formats. Some >> implementations may therefore also support the protection of >> payload packets using the home address as the gateway address.) >> >> In order to support the care-of address as the gateway address >> on the mobile node side, the home agent must act as if the >> gateway address of a security association to the mobile node >> would have changed upon movements. Implementations are free to >> choose any particular method to make this change, such as using >> an API to the IPsec implementation to change the parameters of >> the security association, removing the security association and >> installing a new one, or modification of the packet after it has >> gone through IPsec processing. The only requirement is that >> after registering a new binding at the home agent, the next >> IPsec packets sent on this security association will be >> addressed to the new care-of address." One question that arises is how the MN and HA can use anything other than the "mandatory to implement" encapsulation. For example, if an MN sends a tunneled HOTI packet with SA=CoA and an HAO and the HA doesn't support it, what happens? Presumably the HA sends an error message (which one?) and then the MN MUST use the mandatory-to-implement encapsulation, no? >> "Note that the difficulties with main mode and preshared secrets >> in IKE version 1 are well known for dynamic addresses. With >> static addresses, there has not been a problem. With Mobile >> IPv6, however, the use of the care-of addresses to run IKE >> towards the home agent presents a problem even when the home >> address stays stable." Might add "See Section 7 for details." ------------------------------ Jari Arkko responds to Bernard Aboba: Thanks, I have edited the draft as you suggested. About the question regarding how other formats can be employed: I added the following text to Section 7 about it: Note that packet formats and header ordering discussed in Section 3 must be supported, but implementations may also support other formats. Some implementations may therefore also support the protection of payload packets using the home address as the gateway address. In general, the use of formats not required here may lead to incorrect processing of the packets by the peer (such as silently discarding them), unless support for these formats has been verified off-line. Such verification can take place at the same time the parameters of the security associations are agreed upon. In some cases, however, other specifications call for support of options not discussed here. In these cases such verification step might be unnecessary as long as the peer fully supports the relevant IPv6 specifications. For instance, IPsec specifications call for support of both AH and ESP, and therefore the use of AH should be possible in addition to the required formats that use ESP. However, no claims are made in this document about the validity of these other formats in the context of Mobile IPv6. It is also likely that systems that support Mobile IPv6 have been tested more extensivily with the required formats. ------------------------------ Erik Nordmark responds to Bernard Aboba: > Wouldn't that be required if the incoming tunneled packets to the > HA arrived with SA=CoA and a HAO? Wouldn't the packets tunneled from HA to > MN then have DA=CoA and a RH type 2? I'm missing something. Is the case you are thinking about when the MN tunnels packets to HA with outer SRC=CoA DST=HA HOA inner SRC=HoA DST=CN and that this should somehow effect how packets are tunneled *to* the MN? Unless I'm missing something the protocol isn't specified to work that way, hence the question whether RH type 2 or not is hypothetical; if the protocol was changed to tunnel with HOA one could presumably discuss changing it to tunnel with RH type 2 in the reverse direction. But the less HOA and RH the better - they should really be replaced by encapsulation between the CN and MN as well since it would be cleaner. ------------------------------ Jari Arkko writes: One final thing. The IP-in-IP encapsulation + transport mode vs. IPsec tunnel mode encapsulation. You wrote: > "When IPsec is used to protect return routability signaling or payload > packets, the security policy database entries SHOULD be defined > specifically for the tunnel interface between the mobile node and the > home agent. That is, the policy entries are not generally applied on > all traffic on the physical interface of the nodes but rather only > on the traffic that enters this tunnel." > > Maybe I'm not understanding what you mean here, but this looks to me like > special case IPsec processing. My understanding is that the processing > described above is somewhat more akin to what occurs with transport mode > IP-IP encapsulation than with tunnel mode. See the following draft for more details: > > http://www.ietf.org/internet-drafts/draft-touch-ipsec-vpn-04.txt I have read the draft now. Actually, I don't fully agree with the draft. It seems to say that interface is not a required component in IPsec policy processing. Yet RFC 2401 says "Each interface for which IPsec is enabled requires nominally separate inbound vs. outbound databases (SAD and SPD), ..." and RFC 2460 indicates in Section 2 that the term interfaces / links should include also tunnels. Nevertheless, I do agree with the touch-ipsec-vpn draft in the sense that there are implementations that don't fully support interface-specific policies. So where does this leave us? I have the following proposal: - Change the current language so that it doesn't dictate a particular implementation of tunnel interface. So the text above would change to "When IPsec is used to protect return routability signaling or payload packets, the security policy database entries SHOULD be defined as if they were specifically for the tunnel interface between the mobile node and the home agent. That is, the policy entries are not generally applied on all traffic on the physical interface of the nodes but rather only on the traffic that enters this tunnel." I added the well known "as if they were" weasel words to make it clearer that the implementation does not matter as long as the results are the same on the wire. - Add an informational reference to touch-ipsec-vpn: "Note that this requirement is similar to the approach taken in dynamically routed VPNs [ref]." > Note also that in various places in the document, tunnel mode is required > in preference to transport mode IP-IP, even where manual keying is used. > Since the two are identical on the wire (the difference is in how they are > negotiated within IKE), I am not sure how such a preference can be > enforced. I added this text to the first case where we talk about TUNNEL mode: "Note that this specification concerns itself only with on-the-wire formats, and does not dictate specific implementations mechanisms. In the case of IPsec tunnel mode, the use of IP-in-IP encapsulation followed by IPsec transport mode encapsulation may also be possible. The tradeoffs related to the use of tunnel mode and IP-in-IP encapsulation have been discussed in [ref]." If this is agreeable to you, I think we have addressed everything that you raised in your e-mail. Changes are on the web. ------------------------------ Bernard Aboba responds to Jari Arkko: Thanks. Looks good. ------------------------------ ------------------------------