-------------------- Marcelo Bagnulo (2005-10-12): https://www.machshav.com/pipermail/mobike/2005-October/001117.html 1. I think that in the Introduction, a comment about what is the difference between mobike and what can be achieved with MIP is. I mean, after reading the spec, the difference is clear, but stating it in the introduction would make things easier to understand, especially since the mobility scenario is described there. In particular, stating the it is not a goal of mobike to make changes in the IP address transparent to the upper layers (as stated in the charter for instance) would be useful. 6. In section 3.2. it would make clearer to me if the messages and extensions introduced by mobike (i.e. the actual mobike protocol) where highlighted somehow in the examples (so that it can be distinguished from general IKE exchange) 9. In section 4.4 i think that the Dead Path Detection indication should be mentioned as one of the events that should lead to an address change (perhaps a reference to section 4.9 would be useful too) along with o An IKEv2 request has been re-transmitted several times, but no valid reply has been received. This suggests the current path is no longer working. o An INFORMATIONAL request containing ADDITIONAL_IP4/6_ADDRESS notifications is received. This means the peer's addresses may have changed. o An UNACCEPTABLE_ADDRESSES notification is received as a response to address update request (described below). o The initiator receives a NAT_DETECTION_DESTINATION_IP notification that does not match the previous UPDATE_SA_ADDRESSES response (see Section 4.7 for a more detailed description). (included just to point out which part of the doc i was talking about) 10. In section 4.4, it is stated that: o It updates the IPsec SAs associated with this IKE_SA with the new addresses (unless this was already done before sending the request). As i understand it, the reason for updating the addresses here is because the reply plays the role of a return routability check, right? It would make sense to state so, for instance adding something like o It updates the IPsec SAs associated with this IKE_SA with the new addresses (unless this was already done before sending the request i.e. no return routability check was required, see 4.6). 12. In section 4.6 it is stated that: By default, the return routability check SHOULD be done before updating the IPsec SAs. In environments where the peer is expected to be well-behaved (many corporate VPNs, for instance), or the address can be verified by some other means (e.g., the address is included in the peer's certificate), the return routability check MAY be omitted or postponed until after the IPsec SAs have been updated. I am not sure that the example of the certificate is a good example... what if the certificate is self signed? (i don't know if those are supported) but in any case, i don't know how simple is that certificates can prove address ownership (this depends of the checks performed by the CA about address ownership) 13. Later on, in this section 6.3 it is stated that: It should also be noted, as shown in [Bombing], that without ingress filtering in the attacker's network, such attacks are already possible simply by sending spoofed packets from the attacker to the victim directly. But the whole point of this attack is to achieve amplification, right? I mean, the story that an attacker using a 56kbps starts a download from a heavy server and the redirects it towards a victim flooding it. The point is that the attacker could only send 56kbps, while in this attack, it could redirect the whole server flow through the victim. So, i don't agree with this comment i would suggest to remove it. 14. In section 6.4 it is stated that: Attackers may spoof various indications from lower layers and the network in an effort to confuse the peers about which addresses are or are not working. For example, attackers may spoof link-layer error messages in an effort to cause the parties to move their traffic elsewhere or even to disconnect. Attackers may also spoof information related to network attachments, router discovery, and address assignments in an effort to make the parties believe they have Internet connectivity when, in reality, they do not. This may cause use of non-preferred addresses or even denial-of- service. As i understand this, all non verifiable indications should be used merely as hints. When such a hint is received, the node should perform a Dead Peer Detection, verifying securely, that the path is no longer working. I don't see that these attacks could actually cause dos attacks, but just added DPD traffic. -------------------- Tero Kivinen (2005-10-13): https://www.machshav.com/pipermail/mobike/2005-October/001118.html > 12. In section 4.6 it is stated that: > > By default, the return routability check SHOULD be done before > updating the IPsec SAs. In environments where the peer is expected > to be well-behaved (many corporate VPNs, for instance), or the > address can be verified by some other means (e.g., the address is > included in the peer's certificate), the return routability check MAY > be omitted or postponed until after the IPsec SAs have been updated. > > I am not sure that the example of the certificate is a good example... > what if the certificate is self signed? (i don't know if those are > supported) but in any case, i don't know how simple is that certificates > can prove address ownership (this depends of the checks performed by the > CA about address ownership) If the certificate is self signed, and it is trusted by the recipient there is no problem. The basic idea is that in the VPN case where multiple sites are connected together with VPN gateways each having one or two addresses, each VPN gateway can have certificate which lists the IP-addresses they have. The VPN gateways are not going to get new address on the fly, thus they can use IP-addresses from the certificates. Also the most common case of road warrior will probably be that the gateway is authenticated with certificate and the client is authenticated with some EAP method. In that case it would be useless for clients to do return routability to the server's second address, when the first address happen to go down. -------------------- Marcelo Bagnulo (2005-10-15): https://www.machshav.com/pipermail/mobike/2005-October/001119.html > If the certificate is self signed, and it is trusted by the recipient > there is no problem. The basic idea is that in the VPN case where > multiple sites are connected together with VPN gateways each having > one or two addresses, each VPN gateway can have certificate which > lists the IP-addresses they have. The VPN gateways are not going to > get new address on the fly, thus they can use IP-addresses from the > certificates. Also the most common case of road warrior will probably > be that the gateway is authenticated with certificate and the client > is authenticated with some EAP method. In that case it would be > useless for clients to do return routability to the server's second > address, when the first address happen to go down. > ok -------------------- Jari Arkko (2005-11-06): https://www.machshav.com/pipermail/mobike/2005-November/001263.html I'm looking at the editorial issues and trying to see what exactly needs to be changed. First the ones that I think need a text change: >9. In section 4.4 i think that the Dead Path Detection indication should >be mentioned as one of the events that should lead to an address change >(perhaps a reference to section 4.9 would be useful too) along with > > Suggested change: o An IKEv2 request has been re-transmitted several times, but no valid reply has been received. This suggests the current path is no longer working. => o An IKEv2 request has been re-transmitted several times, but no valid reply has been received. This suggests the current path is no longer working. See also Section 3.9. >10. In section 4.4, it is stated that: > > o It updates the IPsec SAs associated with this IKE_SA with the new > addresses (unless this was already done before sending the > request). > >As i understand it, the reason for updating the addresses here is >because the reply plays the role of a return routability check, right? >It would make sense to state so, for instance adding something like > > o It updates the IPsec SAs associated with this IKE_SA with the new > addresses (unless this was already done before sending the > request i.e. no return routability check was required, see 4.6). > > Ok. The current Section that this text is in is by the way 3.5. > 12. In section 4.6 it is stated that: > > By default, the return routability check SHOULD be done before > updating the IPsec SAs. In environments where the peer is expected > to be well-behaved (many corporate VPNs, for instance), or the > address can be verified by some other means (e.g., the address is > included in the peer's certificate), the return routability check MAY > be omitted or postponed until after the IPsec SAs have been updated. > >I am not sure that the example of the certificate is a good example... >what if the certificate is self signed? (i don't know if those are >supported) but in any case, i don't know how simple is that certificates >can prove address ownership (this depends of the checks performed by the >CA about address ownership) > Right. Suggested text change: s/the address is included in the peer's certificate/the address is included in a certificate given to the peer by a trusted authority/ Then the ones that do not appear to need a text change: >1. I think that in the Introduction, a comment about what is the >difference between mobike and what can be achieved with MIP is. I mean, >after reading the spec, the difference is clear, but stating it in the >introduction would make things easier to understand, especially since >the mobility scenario is described there. In particular, stating the it >is not a goal of mobike to make changes in the IP address transparent to >the upper layers (as stated in the charter for instance) would be useful. > The new introduction makes it quite clear that we are talking about tunnel mode, so the payload traffic & address effects appear to be obvious. We could of course describe what the differences to various other mobility and multihoming protocols are, but I'm not sure that text is easy to write and get consensus on. >6. In section 3.2. it would make clearer to me if the messages and >extensions introduced by mobike (i.e. the actual mobike protocol) where >highlighted somehow in the examples (so that it can be distinguished >from general IKE exchange) > > But I believe hiding this is actually useful for the overview, as people don't have to understand in detail the work split between IKEv2 and MOBIKE. And the information is very explicit in subsequent sections. >13. Later on, in this section 6.3 it is stated that: > > It should also be noted, as shown in [Bombing], that without ingress > filtering in the attacker's network, such attacks are already > possible simply by sending spoofed packets from the attacker to the > victim directly. > >But the whole point of this attack is to achieve amplification, right? I >mean, the story that an attacker using a 56kbps starts a download from a >heavy server and the redirects it towards a victim flooding it. The >point is that the attacker could only send 56kbps, while in this attack, >it could redirect the whole server flow through the victim. So, i don't >agree with this comment i would suggest to remove it. > > The current text already talks about amplification in the same paragraph. The point is that mere flooding without amplification would not be a problem. >14. In section 6.4 it is stated that: > > Attackers may spoof various indications from lower layers and the > network in an effort to confuse the peers about which addresses are > or are not working. For example, attackers may spoof link-layer > error messages in an effort to cause the parties to move their > traffic elsewhere or even to disconnect. Attackers may also spoof > information related to network attachments, router discovery, and > address assignments in an effort to make the parties believe they > have Internet connectivity when, in reality, they do not. > > This may cause use of non-preferred addresses or even denial-of- > service. > >As i understand this, all non verifiable indications should be used >merely as hints. When such a hint is received, the node should perform a >Dead Peer Detection, verifying securely, that the path is no longer >working. > > Well, this isn't strictly speaking true. There are non-verifiable indications that we HAVE to take into account. Or at the very least we know that for such an indication, DPD will surely fail too. For instance, if L2 decides that the link is down, IP and upper layers have way of reversing that decision even if decision was originally based on unverifiable indications. -------------------- Tero Kivinen (2005-11-06): https://www.machshav.com/pipermail/mobike/2005-November/001267.html The certificate is not normally given by trusted authority in the exchange, it is signed by the trusted authority and the other peer normally presents it. On the other hand, I do not see any problem with the original text. If certificate is not trusted by the peer, this will lead the peer to reject the authentication because there is no valid certificate, thus it does not matter what the certificate had. Of course you DO NOT use any information from the any other certificates than from the one that was used in the authentication. Also in some scenarios self-signed certificates with opportunistic approach could be used. If you want to change that text then "the address is inlcuded in the certificate used to authenticate the other peer". -------------------- Pasi Eronen (2005-11-07): https://www.machshav.com/pipermail/mobike/2005-November/001270.html Section 3.9 is about NAT prohibition, and doesn't need to be referenced here?? In -04, Section 4.9 was about path testing, but that's not really very closely related either. IMHO Marcelo's original comment is already handled here: failing DPD == "IKEv2 request has been re-transmitted several times, but no valid reply has been received". My proposal: no text change. The pointer to 4.6/3.5 is IMHO confusing; the real pointer is to the step "Updates the IPsec SAs..." step earlier in this section. How about this? o It updates the IPsec SAs associated with this IKE_SA with the new addresses (unless this was already done earlier before sending the request; this is the case when no return routability check was required). My proposal: [..], or the address can be verified by some other means (e.g., a certificate issued by an authority trusted for this purpose), [...] -------------------- Jari Arkko (2005-11-15) https://www.machshav.com/pipermail/mobike/2005-November/001307.html >My proposal: no text change. > > Ok. >The pointer to 4.6/3.5 is IMHO confusing; the real pointer is to >the step "Updates the IPsec SAs..." step earlier in this section. > > Yes. >How about this? > > o It updates the IPsec SAs associated with this IKE_SA with > the new addresses (unless this was already done earlier > before sending the request; this is the case when no > return routability check was required). > > Ok. > [..], or the address can be verified by some other means > (e.g., a certificate issued by an authority trusted for > this purpose), [...] > > Ok. I think that also addressed Tero's concern with my original text proposal. --------------------