Thomas Narten writes: > 2.2 Return Routability Signaling > > When the Home Test Init messages tunneled to the home agent are > protected by IPsec, they MUST have at least the following headers in > the following order: > > IPv6 header (source = care-of address, > destination = home agent) > ESP header > IPv6 header (source = home address, > destination = correspondent node) > Mobility Header > Home Test Init How is the SA for the outer header set up? Does it require an IKE exchange? (i.e, why doesn't it use the home address option?). Actually, it can't require IKE, since I think this spec doesn't require IKE. But then, how does the above work (say for manually SAs)? This seems like a key bootstrapping issue. Where is it covered in detail in the spec? This question applies in several places. This draft illustrates the use of IPsec in securing control traffic s/draft/document (do this throughout) relating Mobile IPv6 [7]. In Mobile IPv6, a mobile node is always s/relating/relating to/ ? replay protection. The mobile node and the home agent must have an security association to protect this traffic. Furthermore, the great s/have an/have a/ security association to protect this traffic. Furthermore, the great s/the// to Mobile IPv6 home agents. The right kind of addresses must used s/must/must be/ for transporting IKE. This is necessary to ensure that a Binding Update is not needed before the IKE exchange which is needed for securing the Binding Update. maybe rewrite as something like: This is necessary to avoid circular dependencies in which the use of a Binding Update triggers the need for an IKE exchange that cannot complete prior to the Binding Update having been completed. Mobile IPv6 base document defines the main requirements the mobile s/Mobile/The mobile/ This draft discusses these requirements in more depth, illustrates s/draft/document/ All implementations of Mobile IPv6 mobile node and home agent MUST MUST term not defined (check id-nits??) > The Binding Acknowledgements sent back to the mobile node when it is > away from home MUST have at least the following headers in the > following order: > > IPv6 header (source = home agent, > destination = care-of address) > Routing header (type 2) > home address > ESP header > Mobility header > Binding Acknowledgement AH not allowed? Also, ESP AH check doesn't cover the routing header. Is this OK? > 3.1 Mandatory Support > > The following requirements apply to both home agents and mobile > nodes: > > o Manual configuration of security associations MUST be supported. > The configuration of the keys is expected to take place > out-of-band, for instance at the time the mobile node is > configured to use its home agent. > > o Automatic key management with IKE [4] MAY be supported. Only > IKEv1 is discussed in this document, even if it is expected that > the next version of IKE can also be used and that it offers > several improvements in this specific application. > > o IPsec protection for Binding Updates and Acknowledgements between > the mobile node and home agent MUST be supported and MUST be used. > > o IPsec protection for the Home Test Init and Home Test messages > tunneled between the mobile node and home agent MUST be supported > and SHOULD be used. UP to here, you say MUST be supported, and SHOULD be used > > o IPsec protection for the ICMPv6 messages related to prefix > discovery SHOULD be supported and used. > Here you don't say MUST be supported. Consistency? Would it be better to just say early on IPsec MUST be supported, and then right after list on where it should be used... rather than listing the two requirements together on each message type? > o Similarly, a home address within a Type 2 Routing header MUST be > considered as the destination address of the packet, when a packet > is matched against IPsec security policy or selectors of a > security association. This is just a basic requirement of IPv6. Right? If so, it would be good to mention it in those terms (i.e, this is not a special requirement) o Similarly, the authenticator calculation MUST be performed as if a packet with a Home Address destination option would have the home address in the IPv6 source address field and the care-of address in the destination option. is this clear enough for AH, which covers the option? > this protection When the care-of address for the mobile node s/protection/protection./ > determine the shared secret to use from the IP address of the determines Here are the contents of the SPD and SAD for protecting Binding Updates and Acknowledgements in the mobile node mobile node and home agent home agent: extra words? > - IF source = home_address_1 & destination = home_agent_1 & > proto = MH what is "MH"? up thorugh 4.2.2 Return Routability Signaling > replay protection. The mobile node and the home agent must have an s/an/a/ > security association to protect this traffic. Furthermore, the great s/the/// > Mobile IPv6 base document defines the main requirements the mobile insert "The" > 2.2 Return Routability Signaling > > When the Home Test Init messages tunneled to the home agent are > protected by IPsec, they MUST have at least the following headers in > the following order: > > IPv6 header (source = care-of address, > destination = home agent) > ESP header > IPv6 header (source = home address, > destination = correspondent node) > Mobility Header > Home Test Init How is the SA for the outer header set up? Does it require an IKE exchange? (i.e, why doens't is use the home address option?) This question applies in several places. Ditto for the Home Test Message. addresses as IKE was transported on. In order for the home agent to be able to tunnel a Home Test message to the mobile node, it uses the current care-of address as the destination of the tunnel packets, as if the home agent had modified the gateway address of the security association used for this protection. This implies that the same security association can be used in multiple locations, and no new configuration or IKE rekeying is needed per movement. But doesn't the MN initiate the home test init? the HA won't be expecting to see it from the new source address, right? If IPsec is used to protect prefix discovery, requests for prefix s/prefix/prefixes/? > The rules in the following sections apply only to the communications > between home agents and mobile nodes, and should not be taken as > requirements on IPsec in generally is used by mobile nodes. doesn't parse o If multicast group membership control protocols or stateful address autoconfiguration protocols are supported, payload data protection MUST be supported. add "for those protocols" ? o IP layer implementations are, in general, unable to ensure that a particular address of the machine is only used by the user authorized to use that address. Therefore, this specification requires that mobile nodes and home agents SHOULD use credentials that are authorized to control all addresses given to the node. I'm not sure I understand what this means. mobile node moves aways from home again. The security associations protecting Binding Updates and Acknowledgements, and prefix discovery SHOULD not be deleted as they do not depend on care-of addresses and can be used again. how can this me? I thought IPsec required that one compare the source address of recieved packets with what is in the SPD. o When the mobile node receives changed set of prefixes from the s/changed/a changed/ o When the set of prefixes advertised by the home agent changes, there is a need to configure new security policy entries, and there may be a need to configure new security associations. It is outside the scope of this specification to discuss automatic methods for this. actually, only if the prefixes indicate "generate an address". Authentication Header (AH) [2] is also possible but for brevity not discussed in this specification. s/not/is not/ Care is needed when selecting suitable encryption algorithms for ESP. Currently available integrity protection algorithms are in general considered to be secure. The encryption algorithm, DES, mandated by the current IPsec standards is not, however. This is particularly problematic when security associations are configured manually, as the same key is used for a long time. shouldn't this document mandate specific transforms? Or say "implement the ones defined by IPsec?" otherwise, isn't there an ambiguity about what is required to be implemented? o When ESP is used to protect Binding Updates, there is no protection for the care-of address which appears in the IPv6 header outside the area protected by ESP. It is important for the home agent to verify that the care-of address has not been tampered. As a result, the attacker would have redirected the mobile node's traffic to another address. In order to prevent this, Mobile IPv6 implementations SHOULD use the Alternate Care-of seems like a MUST is needed here. Address mobility option in all Binding Updates sent to the home agent. (Note that AH protects also the IPv6 header, and some implementations might avoid the option if they know AH is being used.) o When IPsec is used to protect return routability signaling or payload packets, IPsec security associations are needed to provide this protection When the care-of address for the mobile node changes, special treatment is needed for the next packets sent using these security associations. The home agent MUST set the new care-of address as the destination address of these packets, as if the destination gateway address in the security association had changed. seems like this might be subtle. Is he COA just picked up from the packets indepedent of specific signalling? o If IKE version 1 is used with preshared secrets in main mode, it determine the shared secret to use from the IP address of the peer. With Mobile IPv6, however, this may be a care-of address s/determine/determines/ > proto = MH what is MH? > an IKE packet sent from the mobile node, and the second one is frokm s/frokm/from/ ------------------------- Jari Arkko responds to Thomas Narten: > How is the SA for the outer header set up? Does it require an IKE > exchange? (i.e, why doesn't it use the home address > option?). Actually, it can't require IKE, since I think this spec > doesn't require IKE. But then, how does the above work (say for > manually SAs)? This seems like a key bootstrapping issue. Where is it > covered in detail in the spec? Clarified. > This question applies in several places. > > > This draft illustrates the use of IPsec in securing control traffic > s/draft/document (do this throughout) Done. > relating Mobile IPv6 [7]. In Mobile IPv6, a mobile node is always > > s/relating/relating to/ ? Fixed. > replay protection. The mobile node and the home agent must have an > security association to protect this traffic. Furthermore, the great > > s/have an/have a/ Fixed. > security association to protect this traffic. Furthermore, the great > > s/the// Fixed. > to Mobile IPv6 home agents. The right kind of addresses must used > s/must/must be/ Fixed. > for transporting IKE. This is necessary to ensure that a Binding > Update is not needed before the IKE exchange which is needed for > securing the Binding Update. > > maybe rewrite as something like: > > This is necessary to avoid circular dependencies in which the use > of a Binding Update triggers the need for an IKE exchange that > cannot complete prior to the Binding Update having been completed. Changed, thanks. > Mobile IPv6 base document defines the main requirements the mobile > > s/Mobile/The mobile/ Fixed. I think "Mobile IPv6" appears with "M" though. Now it says "The Mobile IPv6 ..." > This draft discusses these requirements in more depth, illustrates > > s/draft/document/ > > All implementations of Mobile IPv6 mobile node and home agent MUST > > MUST term not defined (check id-nits??) Added. Checked nits too, I think. And I turned on ID-bit checking in XML... > > The Binding Acknowledgements sent back to the mobile node when it is > > away from home MUST have at least the following headers in the > > following order: > > > > IPv6 header (source = home agent, > > destination = care-of address) > > Routing header (type 2) > > home address > > ESP header > > Mobility header > > Binding Acknowledgement > > > AH not allowed? Also, ESP AH check doesn't cover the routing > header. Is this OK? The text in question has changed due to another issue -- it now says 'MUST support at least ...'. This will allow us to talk only about ESP but leave the door open for those who want to do AH. > > 3.1 Mandatory Support > > > > The following requirements apply to both home agents and mobile > > nodes: > > > > o Manual configuration of security associations MUST be supported. > > The configuration of the keys is expected to take place > > out-of-band, for instance at the time the mobile node is > > configured to use its home agent. > > > > o Automatic key management with IKE [4] MAY be supported. Only > > IKEv1 is discussed in this document, even if it is expected that > > the next version of IKE can also be used and that it offers > > several improvements in this specific application. > > > > o IPsec protection for Binding Updates and Acknowledgements between > > the mobile node and home agent MUST be supported and MUST be used. > > > > o IPsec protection for the Home Test Init and Home Test messages > > tunneled between the mobile node and home agent MUST be supported > > and SHOULD be used. > > > UP to here, you say MUST be supported, and SHOULD be used Yes. > > > > o IPsec protection for the ICMPv6 messages related to prefix > > discovery SHOULD be supported and used. > > > > > Here you don't say MUST be supported. Consistency? > > Would it be better to just say early on IPsec MUST be supported, and > then right after list on where it should be used... rather than > listing the two requirements together on each message type? The specific application of IPsec to protecting BUs vs. prefix discovery has a different keyword. This is based on a discussion on the mailing list, where we eventually reached the consensus that for BUs this is a must (both support and use) while for prefix discovery the requirement is not quite as tough. > > o Similarly, a home address within a Type 2 Routing header MUST be > > considered as the destination address of the packet, when a packet > > is matched against IPsec security policy or selectors of a > > security association. > > > This is just a basic requirement of IPv6. Right? If so, it would be > good to mention it in those terms (i.e, this is not a special requirement) I'm not sure this is a basic IPv6 requirement. First of all, *we* are defining Type 2 Routing header. Secondly, I don't trust the IPsec or the IPv6 RFCs to state correctly and in detail how the policy checks are to be performed in the case of these non-trivial cases. > o Similarly, the authenticator calculation MUST be performed as if a > packet with a Home Address destination option would have the home > address in the IPv6 source address field and the care-of address > in the destination option. > > is this clear enough for AH, which covers the option? Is there a particular part of this that you'd like to clarify? I think it is clear enough. > > this protection When the care-of address for the mobile node > > > s/protection/protection./ Fixed. > > determine the shared secret to use from the IP address of the > > > determines Fixed. > Here are the contents of the SPD and SAD for protecting Binding > Updates and Acknowledgements in the mobile node mobile node and home > agent home agent: > > extra words? Fixed. > > - IF source = home_address_1 & destination = home_agent_1 & > > proto = MH > > > what is "MH"? Mobility Header. Clarified now. > addresses as IKE was transported on. In order for the home agent to > be able to tunnel a Home Test message to the mobile node, it uses the > current care-of address as the destination of the tunnel packets, as > if the home agent had modified the gateway address of the security > association used for this protection. This implies that the same > security association can be used in multiple locations, and no new > configuration or IKE rekeying is needed per movement. > > > But doesn't the MN initiate the home test init? the HA won't be > expecting to see it from the new source address, right? The source address need not be considered in the policy checks, and it is not needed for IPsec processing per se. Clarified in the draft, in section 3.2. > If IPsec is used to protect prefix discovery, requests for prefix > > s/prefix/prefixes/? Fixed. > > The rules in the following sections apply only to the communications > > between home agents and mobile nodes, and should not be taken as > > requirements on IPsec in generally is used by mobile nodes. > > > doesn't parse Fixed. > o If multicast group membership control protocols or stateful > address autoconfiguration protocols are supported, payload data > protection MUST be supported. > > add "for those protocols" ? Yes. > o IP layer implementations are, in general, unable to ensure that a > particular address of the machine is only used by the user > authorized to use that address. Therefore, this specification > requires that mobile nodes and home agents SHOULD use credentials > that are authorized to control all addresses given to the node. > > I'm not sure I understand what this means. This is about the situation where users "jarkko" and "tnarten" on the same machine may both be able to use all addresses assigned to the machine, if the OS isn't smart enough to know that I shouldn't be using your home address feed::f00d. I may have credentials that allow me to speak only for "my addresses". We are trying to forbid this, as we can't rely on the IP layer to check that a particular user is using only the correct addresses. For one thing, the address selection draft doesn't require this, I think... > mobile node moves aways from home again. The security > associations protecting Binding Updates and Acknowledgements, and > prefix discovery SHOULD not be deleted as they do not depend on > care-of addresses and can be used again. > > how can this me? I thought IPsec required that one compare the source > address of recieved packets with what is in the SPD. I don't think it requires the check of *outer* source addresses. RFC 2401 does require the capability to do src/dst address and port checks in the SPD. But even there, it is up to the user to specify the actual checks -- these could be wildcards. > o When the mobile node receives changed set of prefixes from the > > s/changed/a changed/ Fixed. > o When the set of prefixes advertised by the home agent changes, > there is a need to configure new security policy entries, and > there may be a need to configure new security associations. It is > outside the scope of this specification to discuss automatic > methods for this. > > actually, only if the prefixes indicate "generate an address". Indicated. > Authentication Header (AH) [2] is also possible but for brevity > not discussed in this specification. > > s/not/is not/ Fixed. > Care is needed when selecting suitable encryption algorithms for > ESP. Currently available integrity protection algorithms are in > general considered to be secure. The encryption algorithm, DES, > mandated by the current IPsec standards is not, however. This is > particularly problematic when security associations are configured > manually, as the same key is used for a long time. > > > shouldn't this document mandate specific transforms? Or say "implement > the ones defined by IPsec?" otherwise, isn't there an ambiguity about > what is required to be implemented? I'd really like to say 'use AES' but that has two kinds of problems. One, not everything that I want is an RFC yet. Two, we are getting pushback from Francis and others on defining too many details. Yet, if you follow the style of documents such as Bernard's IP Storage Security specification... perhaps the best course of action now is to say the IPsec RFCs must be followed. This has now been noted in the new version. > o When ESP is used to protect Binding Updates, there is no > protection for the care-of address which appears in the IPv6 > header outside the area protected by ESP. It is important for the > home agent to verify that the care-of address has not been > tampered. As a result, the attacker would have redirected the > mobile node's traffic to another address. In order to prevent > this, Mobile IPv6 implementations SHOULD use the Alternate Care-of > > seems like a MUST is needed here. We had a MUST originally. However, we changed it to a SHOULD to allow for the use of AH without alt-coa option. I could make it a MUST again, but then I'll have to specify the rules in detail... a SHOULD seemed like a good way to hint that the implementor must really know what he is doing if he is going to avoid it. Ok? > Address mobility option in all Binding Updates sent to the home > agent. (Note that AH protects also the IPv6 header, and some > implementations might avoid the option if they know AH is being > used.) > > o When IPsec is used to protect return routability signaling or > payload packets, IPsec security associations are needed to provide > this protection When the care-of address for the mobile node > changes, special treatment is needed for the next packets sent > using these security associations. The home agent MUST set the > new care-of address as the destination address of these packets, > as if the destination gateway address in the security association > had changed. > > seems like this might be subtle. Is he COA just picked up from the > packets indepedent of specific signalling? No. The care-of address is chosen after an accepted BU. Clarified in the draft. > > an IKE packet sent from the mobile node, and the second one is frokm > > > s/frokm/from/ Changed. ------------------------- Thomas Narten writes: OK, I get it now. I was confused about IPsec and the SPD requirements. I see now that it is a requirement to be able to wildcard the source address for incoming SPDs. But shouldn't this be mentioned somewhere? I don't recall this being said anywhere. I'm OK with all your responses except the following. > > > o IPsec protection for the ICMPv6 messages related to prefix > > > discovery SHOULD be supported and used. > > > > > > > > > Here you don't say MUST be supported. Consistency? > > > > Would it be better to just say early on IPsec MUST be supported, and > > then right after list on where it should be used... rather than > > listing the two requirements together on each message type? > > The specific application of IPsec to protecting BUs vs. prefix > discovery has a different keyword. This is based on a discussion > on the mailing list, where we eventually reached the consensus > that for BUs this is a must (both support and use) while for prefix > discovery the requirement is not quite as tough. I guess I don't understand the subtlety here. If you have to implement IPsec, you have to implement it. Above the "SHOULD" applies to "supported" (which I read as implmented). What's so hard to implement about the above given that you have to implement all this other IPsec stuff? If it is SHOULD be "used", it MUST be implemented, or there may not be an option to use it. > The source address need not be considered in the policy checks, > and it is not needed for IPsec processing per se. Clarified in the > draft, in section 3.2. Here is the new text: {+This format assumes that the mobile node's current care-of address is used as one of the addresses in the security association. As discussed in Section 4.3, this requires the home agent to update the security assocation when the mobile node moves.+} I think the comment about updating the SA is confusing here. THe point here is that the receiver must wildcard the source address in the SPD in order for this packet to be accepted. The stuff in 4.3 won't even happen if the packet is not accepted in the first place. > > o IP layer implementations are, in general, unable to ensure that a > > particular address of the machine is only used by the user > > authorized to use that address. Therefore, this specification > > requires that mobile nodes and home agents SHOULD use credentials > > that are authorized to control all addresses given to the node. > > > > I'm not sure I understand what this means. > > This is about the situation where users "jarkko" and "tnarten" on the > same machine may both be able to use all addresses assigned to the > machine, if the OS isn't smart enough to know that I shouldn't be > using your home address feed::f00d. I may have credentials that allow > me to speak only for "my addresses". We are trying to forbid this, as > we can't rely on the IP layer to check that a particular user is > using only the correct addresses. For one thing, the address > selection draft doesn't require this, I think... All of the above to me seems a bit out of scope to be worried about. Isn't this an OS issue that the IETF has never said anything about? What OSes today control what applications can use what addresses? And this is on a multi-user machine? These are going to be mobile? I don't understand why this text is here. Or maybe this is the tip of an iceberg that you don't want to go near? Note: The use of the words SHOULD and credentials in the same sentence here implies to me some sort of requirement that I have no idea what it means. > > o When ESP is used to protect Binding Updates, there is no > > protection for the care-of address which appears in the IPv6 > > header outside the area protected by ESP. It is important for the > > home agent to verify that the care-of address has not been > > tampered. As a result, the attacker would have redirected the > > mobile node's traffic to another address. In order to prevent > > this, Mobile IPv6 implementations SHOULD use the Alternate Care-of > > > > seems like a MUST is needed here. > > We had a MUST originally. However, we changed it to a SHOULD to allow > for the use of AH without alt-coa option. I could make it a MUST > again, but then I'll have to specify the rules in detail... a SHOULD > seemed like a good way to hint that the implementor must really know > what he is doing if he is going to avoid it. Ok? But the above paragraph seems to talk specifically about ESP, and not AH. So I don't see how your response applies. ------------------------- Jari Arkko responds to Thomas Narten: > OK, I get it now. I was confused about IPsec and the SPD > requirements. I see now that it is a requirement to be able to > wildcard the source address for incoming SPDs. But shouldn't this be > mentioned somewhere? I don't recall this being said anywhere. At first I was started to think about this as well when you asked the questions today. But the thing is, the SPD is matched on the decrypted packets, and by that time the outer header is gone. So I think its OK that the current configuration examples set some conditions on the source address -- its the inner source address. Alternatively, I may have missed a requirement somewhere in RFC 2401 that says something about the outer header checks. Vijay, can you confirm? > I'm OK with all your responses except the following. > > >> > > o IPsec protection for the ICMPv6 messages related to prefix >> > > discovery SHOULD be supported and used. >> > > >> > >> > >> > Here you don't say MUST be supported. Consistency? >> > >> > Would it be better to just say early on IPsec MUST be supported, and >> > then right after list on where it should be used... rather than >> > listing the two requirements together on each message type? > > >>The specific application of IPsec to protecting BUs vs. prefix >>discovery has a different keyword. This is based on a discussion >>on the mailing list, where we eventually reached the consensus >>that for BUs this is a must (both support and use) while for prefix >>discovery the requirement is not quite as tough. > > > I guess I don't understand the subtlety here. If you have to implement > IPsec, you have to implement it. Above the "SHOULD" applies to > "supported" (which I read as implmented). What's so hard to implement > about the above given that you have to implement all this other IPsec > stuff? If it is SHOULD be "used", it MUST be implemented, or there may > not be an option to use it. IPsec MUST be implemented per IPv6 requirements. What we are talking about here I guess is the specific way to use IPsec for protecting MIPv6. In some cases (such as for the RR tunnel protection) we set requirements that are not fulfilled by the basic IPsec mechanisms; in some other cases we define a "profile" for using IPsec for a particular purpose. The prefix discovery protection is an example of the latter. As far as I know, there's nothing in that a correctly implemented IPv6 node shouldn't be able to do. However, such specification may still be relevant for two reasons: - Ensuring interoperability by reducing the number of options - Providing a profile for implementations that have some level of automated set-up support for this (as opposed to requiring the users set SPD etc up manually) So where does this leave us? Following the RFCs, IPsec must be implemented in any case, and the required level of support is sufficient to allow users set-up SPD by themselves for protecting prefix discovery. For that, we might make it a MUST support and there'd be no difference to implementations. Does it matter for interoperability and automated set-up support? I'm not sure because we don't specifically require any support like that in the document. Vijay, do you have a comment? Perhaps you could ask TJ what he thinks too. >>The source address need not be considered in the policy checks, >>and it is not needed for IPsec processing per se. Clarified in the >>draft, in section 3.2. > > > Here is the new text: > > {+This format assumes that the mobile node's current care-of address is > used as one of the addresses in the security association. As > discussed in Section 4.3, this requires the home agent to update the > security assocation when the mobile node moves.+} > > > I think the comment about updating the SA is confusing here. THe point > here is that the receiver must wildcard the source address in the SPD > in order for this packet to be accepted. The stuff in 4.3 won't even > happen if the packet is not accepted in the first place. Wildcard in the processing of the tunnel packet, I think. The inner packet uses home addresses. SPD is only for the inner packet. >> > o IP layer implementations are, in general, unable to ensure that a >> > particular address of the machine is only used by the user >> > authorized to use that address. Therefore, this specification >> > requires that mobile nodes and home agents SHOULD use credentials >> > that are authorized to control all addresses given to the node. >> > >> > I'm not sure I understand what this means. > > >>This is about the situation where users "jarkko" and "tnarten" on the >>same machine may both be able to use all addresses assigned to the >>machine, if the OS isn't smart enough to know that I shouldn't be >>using your home address feed::f00d. I may have credentials that allow >>me to speak only for "my addresses". We are trying to forbid this, as >>we can't rely on the IP layer to check that a particular user is >>using only the correct addresses. For one thing, the address >>selection draft doesn't require this, I think... > > > All of the above to me seems a bit out of scope to be worried > about. Isn't this an OS issue that the IETF has never said anything > about? What OSes today control what applications can use what > addresses? And this is on a multi-user machine? These are going to be > mobile? > > I don't understand why this text is here. Or maybe this is the tip of > an iceberg that you don't want to go near? That's right. Basically, the text is in the document because someone who knows a lot about IKE was worried about this. So we wanted to explicitly say that we don't do that. > Note: The use of the words SHOULD and credentials in the same sentence > here implies to me some sort of requirement that I have no idea what > it means. I'll try to clarify it. >> > o When ESP is used to protect Binding Updates, there is no >> > protection for the care-of address which appears in the IPv6 >> > header outside the area protected by ESP. It is important for the >> > home agent to verify that the care-of address has not been >> > tampered. As a result, the attacker would have redirected the >> > mobile node's traffic to another address. In order to prevent >> > this, Mobile IPv6 implementations SHOULD use the Alternate Care-of >> > >> > seems like a MUST is needed here. > > >>We had a MUST originally. However, we changed it to a SHOULD to allow >>for the use of AH without alt-coa option. I could make it a MUST >>again, but then I'll have to specify the rules in detail... a SHOULD >>seemed like a good way to hint that the implementor must really know >>what he is doing if he is going to avoid it. Ok? > > > But the above paragraph seems to talk specifically about ESP, and not > AH. So I don't see how your response applies. Ok, perhaps I can change it then. ------------------------- Vijay Devarapalli responds to Jari Arkko: > Alternatively, I may have missed a requirement somewhere > in RFC 2401 that says something about the outer header > checks. Vijay, can you confirm? for tunnel mode, the selector match is done on the inner IPv6 header. from RFC 2401 > 2. Use the SA found in (1) to do the IPsec processing, e.g., > authenticate and decrypt. This step includes matching the > packet's (Inner Header if tunneled) selectors to the > selectors in the SA. for transport mode, when the home agent receives the BU, the home address option is processed first (because it appears before the IPsec header). when the packet reaches the MIPv6 module, the source address of the packet is the home address. so the source address selector match works. > So where does this leave us? Following the RFCs, IPsec must > be implemented in any case, and the required level of support > is sufficient to allow users set-up SPD by themselves for > protecting prefix discovery. For that, we might make it a MUST > support and there'd be no difference to implementations. Does > it matter for interoperability and automated set-up support? > I'm not sure because we don't specifically require any support > like that in the document. > > Vijay, do you have a comment? Perhaps you could ask TJ what > he thinks too. there is a subtle difference. some implementations do not treat ICMP as a payload protocol. they just look for UDP, TCP.... in this context it makes sense to say IPsec protection for mobile prefix discovery is a 'SHOULD implement' and 'SHOULD' use. but if you go by RFC 2401, ICMP protection should be there in every IPsec implemenation. then it probably doesnt make sense to say 'MUST implement' for protecting Mobility Header and 'SHOULD implement' for protection ICMP prefix discovery. I am fine either way. ------------------------- Jari Arkko responds to Thomas Narten: > Here is the new text: > > {+This format assumes that the mobile node's current care-of address is > used as one of the addresses in the security association. As > discussed in Section 4.3, this requires the home agent to update the > security assocation when the mobile node moves.+} > > > I think the comment about updating the SA is confusing here. THe point > here is that the receiver must wildcard the source address in the SPD > in order for this packet to be accepted. The stuff in 4.3 won't even > happen if the packet is not accepted in the first place. Ok. New text should make this clearer: "This format assumes that the mobile node's current care-of address is used as one of the gateway addresses in the security association. As discussed in , this requires the home agent to update the gateway address when the mobile node moves. Policy entries and security association selectors stay the same, however, as the inner packets do not change upon movements." > Note: The use of the words SHOULD and credentials in the same sentence > here implies to me some sort of requirement that I have no idea what > it means. New text: "The authentication of mobile nodes MAY be based either on machine or user credentials. Note that multi-user operating systems typically allow all users of a node to use any of the IP addresses assigned to the node. This limits the capability of the home agent to restrict the use of a home address to a particular user in such environment. Where user credentials are applied in a multi-user environment, the configuration should authorize all users of the node to control all home addresses assigned to the node." Is this better? >> > o When ESP is used to protect Binding Updates, there is no >> > protection for the care-of address which appears in the IPv6 >> > header outside the area protected by ESP. It is important for the >> > home agent to verify that the care-of address has not been >> > tampered. As a result, the attacker would have redirected the >> > mobile node's traffic to another address. In order to prevent >> > this, Mobile IPv6 implementations SHOULD use the Alternate Care-of >> > >> > seems like a MUST is needed here. > > >>We had a MUST originally. However, we changed it to a SHOULD to allow >>for the use of AH without alt-coa option. I could make it a MUST >>again, but then I'll have to specify the rules in detail... a SHOULD >>seemed like a good way to hint that the implementor must really know >>what he is doing if he is going to avoid it. Ok? > > > But the above paragraph seems to talk specifically about ESP, and not > AH. So I don't see how your response applies. Changed to a MUST. ------------------------- Jari Arkko writes: I have thought about the one remaining part (SHOULD support prefix discovery protection with IPSec) some more. I note that (1) we are not specifying anything about any automated MIPv6-specific support for setting up these SAs, (2) no IPsec modifications are needed, and (3) IPsec implementations, while not very good in treating random protocol numbers, often tend to implement ICMP support simply due to testing needs. I think the conclusion is that the support is MUST, even if the use is a SHOULD. Text follows. In Section 6.7 and 6.8: o IPsec headers MUST be supported and SHOULD be used as described in Section . In Section 10.6.3: o IPsec headers MUST be supported and SHOULD be used. In Section 11.4.2: o The mobile node MUST use the Home Address destination option to carry its home address. The mobile node MUST support and SHOULD use IPsec to protect the solicitation. In the HA-MN IPsec draft, Section 4.1: o IPsec protection for the ICMPv6 messages related to prefix discovery MUST be supported and SHOULD be used. ------------------------- ------------------------- ------------------------- ------------------------- ------------------------- -------------------------