Hi,I read through ietf-hip-rfc5206-bis-10, and it is in pretty good shape. Below are a few nits.
> 3.1. Operating Environment > > [...] > > Consider next a mobility event, in which a host moves to another IP > address. Two things must occur in this case. First, the peer must > be notified of the address change using a HIP UPDATE message. > Second, each host must change its local bindings at the HIP sublayer > (new IP addresses). It may be that both the SPIs and IP addresses > are changed simultaneously in a single UPDATE; the protocol described > herein supports this. However, elements of procedure to recover from I think simultaneous mobility is covered as already mentioned in the intro? > 3.2.3. Mobility messaging through rendezvous server > > 3. A host receiving an UPDATE packet MUST be prepared to process the > FROM and RVS_HMAC parameters, and MUST include a VIA_RVS > parameter in the UPDATE reply that contains the ACK of the UPDATE > SEQ. (I would add that the return routability test should be invoked to the end-host's addresses rather than the ones in VIA_RVS) > 4. This scenario requires that hosts using rendezvous servers also > take steps to update their current address bindings with their > rendezvous server upon a mobility event. > [I-D.ietf-hip-rfc5204-bis] does not specify how to update the > rendezvous server with a client host's new address. > [I-D.ietf-hip-rfc5203-bis] Section 3.2 describes how a host may > send a REG_REQUEST in either an I2 packet (if there is no active > association) or an UPDATE packet (if such association exists). (Maybe this should have been actually step 0) > The procedures described in [I-D.ietf-hip-rfc5203-bis] for > sending a REG_REQUEST and REG_RESPONSE to the rendezvous server > apply also to this mobility scenario. This was a bit vague, how? > 3.2.4. Network Renumbering > > It is expected that IPv6 networks will be renumbered much more often > than most IPv4 networks. From an end-host point of view, network > renumbering is similar to mobility. ...and? > 3.3. Other Considerations > > 3.3.1. Address Verification > > When a HIP host receives a set of locators from another HIP host in a > LOCATOR_SET, it does not necessarily know whether the other host is > actually reachable at the claimed addresses. In fact, a malicious > peer host may be intentionally giving bogus addresses in order to > cause a packet flood towards the target addresses [RFC4225]. > Therefore, the HIP host must first check that the peer is reachable > at the new address. > > An additional potential benefit of performing address verification is > to allow middleboxes in the network along the new path to obtain the > peer host's inbound SPI. > > Address verification is implemented by the challenger sending some > piece of unguessable information to the new address, and waiting for > some acknowledgment from the Responder that indicates reception of > the information at the new address. This may include the exchange of > a nonce, or the generation of a new SPI and observation of data > arriving on the new SPI. I suggest would move the second paragraph after the third one. > 3.3.2. Credit-Based Authorization > > On this basis, rather than eliminating malicious packet redirection > in the first place, Credit-Based Authorization prevents > amplifications. This is accomplished by limiting the data a host can > send to an unverified address of a peer by the data recently received > from that peer. Redirection-based flooding attacks thus become less > attractive than, for example, pure direct flooding, where the > attacker itself sends bogus packets to the victim. Reference section 5.6? > 4.3. UPDATE Packet with Included LOCATOR_SET > > A number of combinations of parameters in an UPDATE packet are > possible (e.g., see Section 3.2). In this document, procedures are > defined only for the case in which one LOCATOR_SET and one ESP_INFO > parameter is used in any HIP packet. Furthermore, the LOCATOR_SET > SHOULD list all of the locators that are active on the HIP > association (including those on SAs not covered by the ESP_INFO > parameter). What do you mean by "including those on SAs..."? > Any UPDATE packet that includes a LOCATOR_SET parameter > SHOULD include both an HMAC and a HIP_SIGNATURE parameter. Please add a paragraph break here. > The UPDATE MAY also include a HOST_ID parameter (which may be useful for > middleboxes inspecting the HIP messages for the first time). If the > UPDATE includes the HOST_ID parameter, the receiving host MUST verify > that the HOST_ID corresponds to the HOST_ID that was used to > establish the HIP association, and the HIP_SIGNATURE must verify with > the public key assodiated with this HOST_ID parameter. assodiated -> associated Please add a paragraph break here. > The relationship between the announced Locators and any ESP_INFO > parameters present in the packet is defined in Section 5.2. This > draft does not support any elements of procedure for sending more > than one LOCATOR_SET or ESP_INFO parameter in a single UPDATE. draft -> document > 5.4. Verifying Address Reachability > > A host typically starts the address-verification procedure by sending > a nonce to the new address. For example, when the host is changing > its SPI and sending an ESP_INFO to the peer, the NEW SPI value SHOULD > be random and the value MAY be copied into an ECHO_REQUEST sent in > the rekeying UPDATE. (The copying is an implementation strategy) > However, if the host is not changing its SPI, > it MAY still use the ECHO_REQUEST parameter in an UPDATE message sent > to the new address. For what? > 5.5. Changing the Preferred Locator > > [...] > > 3. If the peer host has not indicated a preference for any address, > then the host picks one of the peer's ACTIVE addresses randomly > or according to policy. This case may arise if, for example, local policy > 5.6. Credit-Based Authorization > > To prevent redirection-based flooding attacks, the use of a Credit- > Based Authorization (CBA) approach is mandatory when a host sends > data to an UNVERIFIED locator. The following algorithm meets the > security considerations for prevention of amplification and time- > shifting attacks. Other forms of credit aging, and other values for > the CreditAgingFactor and CreditAgingInterval parameters in mandatory or MUST? > 6. Security Considerations > > In Section 6.1 and Section 6.2, we assume that all users are using > HIP. In Section 6.3 we consider the security ramifications when we > have both HIP and non-HIP users. Security considerations for Credit- > Based Authorization are discussed in [SIMPLE-CBA]. users -> hosts? > 6.1. Impersonation Attacks > > An attacker wishing to impersonate another host will try to mislead > its victim into directly communicating with them, or carry out a man- > in-the-middle (MitM) attack between the victim and the victim's > desired communication peer. Without mobility support, both attack > types are possible only if the attacker resides on the routing path > between its victim and the victim's desired communication peer, or if > the attacker tricks its victim into initiating the connection over an > incorrect routing path (e.g., by acting as a router or using spoofed > DNS entries). Without HIP and its mobility support, ... By the way, I didn't get why the lack of mobility support can lead MiTM attacks? > The HIP extensions defined in this specification change the situation > in that they introduce an ability to redirect a connection (like > IPv6), both before and after establishment. If no precautionary like in IPv6 (why is this an issue for IPv6, btw?) > measures are taken, an attacker could misuse the redirection feature > to impersonate a victim's peer from any arbitrary location. The > authentication and authorization mechanisms of the HIP base exchange > [RFC7401] and the signatures in the UPDATE message prevent this > attack. Furthermore, ownership of a HIP association is securely > linked to a HIP HI/HIT. If an attacker somehow uses a bug in the > implementation or weakness in some protocol to redirect a HIP what protocol? > MitM attacks are always possible if the attacker is present during > the initial HIP base exchange and if the hosts do not authenticate > each other's identities. However, once the opportunistic base ...once such an opportunistic... > exchange has taken place, even a MitM cannot steal the HIP connection > anymore because it is very difficult for an attacker to create an > UPDATE packet (or any HIP packet) that will be accepted as a > legitimate update. UPDATE packets use HMAC and are signed. Even > when an attacker can snoop packets to obtain the SPI and HIT/HI, they > still cannot forge an UPDATE packet without knowledge of the secret > keys. Also, replay attacks are impossible because the HMAC keys are and nonces echo_requests are new. > 6.2.1. Flooding Attacks > > > An effective DoS strategy is distributed denial of service (DDoS). > Here, the attacker conventionally distributes some viral software to > as many nodes as possible. Under the control of the attacker, the > infected nodes, or "zombies", jointly send packets to the victim. > With such an 'army', an attacker can take down even very high > bandwidth networks/victims. zombies -> botnets > With the ability to redirect connections, an attacker could realize a > DDoS attack without having to distribute viral code. Here, the > attacker initiates a large download from a server, and subsequently > redirects this download to its victim. via HIP mobility UPDATE, right? > 6.2.2. Memory/Computational-Exhaustion DoS Attacks > > We now consider whether or not the proposed extensions to HIP add any > new DoS attacks (consideration of DoS attacks using the base HIP > exchange and updates is discussed in [RFC7401]). A simple attack is > to send many UPDATE packets containing many IP addresses that are not > flagged as preferred. The attacker continues to send such packets > until the number of IP addresses associated with the attacker's HI > crashes the system. Therefore, there SHOULD be a limit to the number > of IP addresses that can be associated with any HI. where there? > A central server that has to deal with a large number of mobile > clients may consider increasing the SA lifetimes to try to slow down > the rate of rekeying UPDATEs or increasing the cookie difficulty to > slow down the rate of attack-oriented connections. may or MAY? > 6.3. Mixed Deployment Environment > > We now assume an environment with both HIP and non-HIP aware hosts. > Four cases exist. > > 4. A HIP host attempts to steal a non-HIP host's session. A HIP > host could spoof the non-HIP host's IP address during the base > exchange or set the non-HIP host's IP address as its preferred > address via an UPDATE. Other possibilities exist, but a simple > solution is to prevent the use of HIP address check information > to influence non-HIP sessions. er... how?
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
