Hi Tom, hi all, please find my feedback in-line.
On 12 Dec 2014, at 02:09, Tom Henderson <[email protected]> wrote: > Hi all, I recently published the version -07 draft of RFC5206-bis > (mobility support in HIP). This was merely a refresh of -06; I'd like > to now start moving through and closing the remaining open issues so we > can get the document into shape for WGLC. > > I made a pass through the document and plan to publish the following > (IMO) minor changes in version -08 next week, if there are no > objections. Separately, I will start threads on remaining open issues > that require some discussion on the list. > > Section 3.2 Protocol Overview > ------------------------------ > The draft states: > > However, some implementations may want to experiment with sending > LOCATOR_SET parameters also on other packets, such as R1, I2, and > NOTIFY. > > I propose to delete this sentence since we are no longer experimental; +1 I would actually propose to completely remove all mentioning of the LOCATOR_SET parameter from any message type but UPDATE within the context of this document in order to simplify host mobility to a single procedure (UPDATE with LOCATOR_SET). If, e.g., multi-homing, prefers the LOCATOR_SET parameter in other messages, a separate document can specify this message flow. > later in the document (section 5.3), it states that: > > A host SHOULD be prepared to receive a LOCATOR_SET parameter in the > following HIP packets: R1, I2, UPDATE, and NOTIFY. > > and it leaves open to the implementation (Section 5.2) when to send such > a packet. More on this later. See comment above. > (also) Section 3.2: > ------------------ > The draft states: > > The scenarios below at times describe addresses as being in either an > ACTIVE, VERIFIED, or DEPRECATED state. > > 'VERIFIED' is a typo; it should be ‘UNVERIFIED' +1 > 3.2.1 Mobility with a Single SA Pair (No Rekeying) > --------------------------------------------------- > The draft states: > > This first example considers the > case in which the mobile host has only one interface, IP address, a > single pair of SAs (one inbound, one outbound), and no rekeying > > I propose to clarify 'IP address' as rather 'one IP address in use > within the HIP session', since it is seldom the case now that hosts have > one IP address system-wide, and what is really intended here is to talk > about the case for which there is only one IP address in use. +1 > 3.2.3. Using LOCATOR_SETs across Addressing Realms > -------------------------------------------------- > I propose to delete this section for now; we have an open issue > (http://trac.tools.ietf.org/wg/hip/trac/ticket/5) to better define > cross-family handovers, and I'd like to later propose different text > based on the work published in "Secure and Efficient IPv4/IPv6 Handovers > Using Host-based Identifier-Locator Split" by Varjonen et al. Why don’t you simply replace this section with your text in an upcoming revision? I don’t see the benefit in removing this section right now without a proper replacement. > 4.3 UPDATE Packet with Included LOCATOR_SET > -------------------------------------------- > There is a sentence that says: > > The > sending of multiple LOCATOR_SET and/or ESP_INFO parameters is for > further study; receivers may wish to experiment with supporting such > a possibility. > > I propose to delete this since supporting it is more complicated and I > am not sure of the use case. +1 What about mandating a _single_ LOCATOR_SET parameter per HIP packet? > 5.1. Locator Data Structure and Status > -------------------------------------- > The draft states: > > In a typical implementation, each outgoing locator is represented by > a piece of state that contains the following data: > > I propose to clarify this by deleting 'outgoing locator' and replacing > with 'locator known about the peer' since outgoing might be interpreted > instead as the source address. What about saying ‘each locator announced in a LOCATOR_SET parameter’? > I would also like to add these two sentences to the end of this subsection: > > In addition, an implementation would typically maintain similar > state about its own locators offered to the peer. I wouldn’t mind about adding this text. > Finally, the locators used to establish the HIP association are > by default assumed to be the initial preferred locators in > ACTIVE state, with an unbounded lifetime. +1 > 5.2. Sending LOCATOR_SETs > ------------------------- > The lead sentence states: > > The decision of when to send LOCATOR_SETs is basically a local policy > issue. > > I propose to add: "LOCATOR_SET parameters MAY be included in HIP packet > types of R1, I2, R2, UPDATE, and NOTIFY." > > We have previously not included R2 in this list, but the work published > in "Secure and Efficient IPv4/IPv6 Handovers Using Host-based > Identifier-Locator Split" by Varjonen et al. discussed some benefits > found by allowing the parameter also in R2. I admit that I didn’t read the referenced paper. Still, I think we should make the mobility procedure plain simple. I therefore suggest to only specify the use of the LOCATOR_SET parameter in UPDATE messages. > There is also a paragraph that states: > > Note that the purpose of announcing IP addresses in a LOCATOR_SET is > to provide connectivity between the communicating hosts. In most > cases, tunnels or virtual interfaces such as IPsec tunnel interfaces > or Mobile IP home addresses provide sub-optimal connectivity. > Furthermore, it should be possible to replace most tunnels with HIP > based "non-tunneling", therefore making most virtual interfaces > fairly unnecessary in the future. Therefore, virtual interfaces > SHOULD NOT be announced in general. On the other hand, there are > clearly situations where tunnels are used for diagnostic and/or > testing purposes. In such and other similar cases announcing the IP > addresses of virtual interfaces may be appropriate. > > I'd like to reduce this to the following: > > Locators corresponding to tunnel interfaces (e.g. IPsec tunnel > interfaces or Mobile IP home addresses) or other virtual > interfaces MAY be announced in a LOCATOR_SET, but implementations > SHOULD avoid announcing such locators as preferred locators if > more direct paths may be obtained by instead preferring locators > from non-virtual interfaces. +1 but I would replace “ more direct paths may be obtained by instead preferring locators from non-virtual interfaces” with “non-tunneling interface and their locator(s) provide more direct path to the HIP peer”. > 5.3. Handling Received LOCATOR_SETs > ----------------------------------- > The draft states: > > A host SHOULD be prepared to receive a LOCATOR_SET parameter in the > following HIP packets: R1, I2, UPDATE, and NOTIFY. > > Similar to the proposal in 5.2 above, I'd like to change to: > > A host SHOULD be prepared to receive a LOCATOR_SET parameter in the > following HIP packets: R1, I2, R2, UPDATE, and NOTIFY. See my above comment. BR René -- Dipl.-Inform. Rene Hummen, Ph.D. Student Chair of Communication and Distributed Systems RWTH Aachen University, Germany tel: +49 241 80 21426 web: http://www.comsys.rwth-aachen.de/team/rene-hummen/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
