HIPRG IETF-73 meeting minutes ----------------------------- Meeting Friday 0900-1100 November 21, 2008, in the Duluth Room. Meeting chaired by Tom Henderson (co-chair Andrei Gurtov was absent) Notes compiled by Andrew McGregor and edited by Tom Henderson 1. Agenda overview (no discussion) ----------------------------------- 2. HIP Extensions for Object-to-Object Communications -- draft-lee-hip-object-01.txt presented by Gyu Myoung Lee (GML) --------------------------------- Updates since the last draft/presentation: - additional co-author Seng Kyoun Jo - minor updates from last meeting regarding mapping/binding for communications between objects, specify a common identifier, some text on specific use cases ITU-T is developing some relevant recommendations (Y.NGN-UbiNet). Suggesting that IETF can develop the protocol solution with ITU-T defining requirements and architecture, and ISO/IEC developing industrial standards. Would like to specify a common identifier and unified format, and proposing Object identifiers and object identity tags (OIT). Expand HIP to include concept of object. Author would like to propose this as a research group item. Questions: Tim Shepard (TS): What are the security properties of the OITs? GML: They're hashes or encrypted versions of the object's assigned numbers such as their RFID. Bob Moskowitz (BM): Have to go back to namespace research group. Original problem: what does the HI apply to? What are you identifying? For convenience, HI applied to network stack... however, this is an artifact of existing code and practice. The intent was that the HI should apply to any object within the architecture. There was discussion of whether the object itself should support the crypto, or rely on a midbox. There are many namespaces, therefore there is need to do bindings. All we have right now is HI<->DNS bindings. This is not a limitation of HIP. Your proposal seems to be a binding between the OID and HI, without requiring to go elsewhere... by supplying the binding in-band. There is provision for transporting these bindings in the protocol already. In this situation the RFID reader is a midbox (for example) to the RFID tag, and the object (RFID tag) is addressable through it. What should be done here is more in terms of: OID is bound to HI. This may have thousands of OIDs per HI. Reader may construct a HI per OID, or maybe not. We have many names, names in themselves cannot be trusted. Here we need a binding. Look into this: every single object needs its own HIT, which must be bound because the name is not cryptographic, but you can maintain a binding. Do not limit efforts to: one host->one HI, instead give each object an identity to which its name is bound. TS: Bob pointed out: you can have many IDs per host. The question is: why not use HITs; why do you need an OID? BM: Because RFIDs exist. GML: We can provide direct connection between user and object. Without this sort of mechanism, we'll have to put extra information in the DNS. TH: Have you considered the work on HIP Certs? There is a binding mechanism between arbitrary names and HIs via certificates. This appears to be a suitable binding mechanism. GML: We do not have a detailed security solution yet. BM: There are known problems with hashing one known number on top of something else... security problems aren't good. If you go to RFC 5201, section 5.2 the TLVs include a HOST_ID TLV that contains an FQDN. Point here is that any string that identifies an object can be carried inside the HIP exchange with the HostID parameter, or if necessary with a new TLV. This does not create crypto questions where we hash a known string on top of the HIT, but instead binds it to the exchange. Now you have O-O communication within the existing exchange. AM (Andrew McGregor): No issue with goals, but... aren't you trying to solve this at the wrong layer? The RFID tag or name has to be moved back a step and into the crypto keys, not replacing them, because that would break the other mechanisms of the protocol. TH: Do we need RG work on this problem? BM: Great value to do it, but put this within the existing exchange. Can we do it in a manner that doesn't add risk/complexity? TS: (not sure he's understood much here) What is the problem? Would be helpful to clarify the problem, and justify why we can't use what we already have. TH: Could we have some use cases? In the present draft this is a bit underspecified... more detailed development would be nicer. TS: Making an argument that there's a technology gap implies that there's a need to explain why existing mechanisms are insufficient. BM: Problem is to change the use of HIP from stack communication to object communication GML: Objects considered "inside" the host. HIP does not appear to deal with this. BM: HIP allows for outer protocol variation. Why do I mention this? When there's no IP on an object... there's nothing within the HIP architecture that prevents this, with HIP running on the object... of course this assumes the object is capable of running HIP. You could have used IPX as the outer layer. TH: To BM: I agree that the internetworking layer is interchangeable... but what about the next layer up? All the discussion has been about socket-like connection. What does it mean to communicate with an object? When you want to talk to a URI or phone number, there's an implicit service from a protocol perspective-- are you suggesting that you would map HIP into a telephony architecture? GML: telephony has an ENUM structure; we can reuse that. In case of RFID we'd like serverless communication to the object BM: you can use RFID protocol as internetworking layer... of course that blows the cost model of the RFID chips. This leads to a midbox model because an object is either legacy or does not have the processing. In the IETF we've got rather stuck on internetworking == IP... but this should not be limiting MP (Mike Patton): I'm having flashbacks to NIMROD... where we called the identifier an endpoint ID. I think some of the confusion is the necessity to map object to host... this isn't necessary. HI doesn't have to identify a host. The object might not be able to run the protocol itself, which then needs a proxy. Host then proxys for the object. BM: NIMROD was in the picture. TS: MP reminded me that HIP is poorly named. TH: This appears to be an interesting problem. Better use cases. TS: It seems that we have app layer IDs of some sort. There is some desire to move them down the stack... there are different ways you might build the system. TH: Willing to refine problem statement? AM: It's clear how to push app IDs down the stack... the feeling of the group seems to be that we need to better explain why to do it, and what the right way to do it is. 3. Delivering Geographic Location in HIP -- draft-cao-hip-geolocation-01.txt presented by Hui Deng (HD) ---------------------------------------- Questions: Richard Barnes (RB, geopriv chair): It doesn't seem to be in the right place in the stack. Determining location, you want to be as close as possible to the physical interface, and on the other hand, once you have location information, conveying it from place to place is an application layer function. There doesn't seem to be a clear motivation for using this layer for talking about the location? TS: I think this may be the same question; you propose that we carry this location within the HIP layer, why not above the HIP layer? HD: Applications may not be aware of the operator network. Also, there may be multiple applications that could leverage information in the HIP layer. BM: Interesting. But RB bought up a very interesting case: multi-homed host. What is in fact the location of such a host? Host may have multiple locations. HD: That's very interesting... big challenge there. Location can be IP address, but that's not very stable or nice. True geographic information (e.g., GPS) may be applicable in the multi-homing case. RB: multihoming is increasingly common. Protocol could carry multiple locations. BM: App would not know which interface is being used TH: Interpretation is that providing this information in HIP does not help HIP, instead it is using HIP for a transport. Are there inadequate mechanisms elsewhere, or does this plug a gap in geopriv? Also, there is now in the HIP working group the notion of HIP datagram service, using HIP as a transport-- could that be used? RB: HIP could offer a generic secure channel? (TH: yes) Geopriv has various app protocols. There's an HTTP proposal. So app extensions is an area of interest. This could serve as a convergence layer between multiple apps. It would help to understand better to understand why hosts might want to do this. BM: making geolocation an app responsibility might well be a punt. Since location is a function of where the host is, it's a lower layer function, but we've punted to the application layer. SIP now needs to provide this because they have to. However, if we can provide a solid reliable private geo-notification, it becomes a powerful tool in our toolkit. AM: Rather than being a new locator type, this belongs in its own TLVs, inside encrypted payload. RB: Recommend instead to use RFC4119 format for these, with privacy rules attached TH: to move forward with this: discussion on if we should do this at HIP layer. Privacy is an issue. Take this issue to the list to try to work through these issues. AM: I've changed my mind... this really does belong at this level in the stack, because here we can do bindings. RB: Would like to take discussion into geopriv too TS: Theme here... both discussions of doing something app layer like, which would be nice to not implement over per app... why not extend a lower layer to do this. Are all of these things application layer pressure to grow the HIP layer? Is this all really in scope? BM: Disagree, location is a lower than app function. This is a system function, that might be done by an application, for instance a GPS service RB: Location is weird for networking... it's close to physical, but pretty much no use to intermediate layers. HIP is in the middle... is it really a good match? HD: this was the original internet design. But mobility is coming to the internet... location is a cross-provider, even, tool. This is intended to be more of a service than app. 4. Update on the HIP-based Secure Mobile Architecture project at Boeing presented by Tom Henderson (TH) -------------------------------- Questions: TS: What sits between these boxes is just a cloud? Do they do DHCP? TH: Yes. DHCP and manual configuration are both possible... we're transitioning to automatic configuration. TS: How do you discover which IP devices are behind each box TH: Manual configuration for now, although MAC address discovery is automated TS: TRILL? Is this related? TH: can't answer right now BM: recommends taking the public tour in Boeing sometime and taking a look at how this is used. Do the HIP boxes have a separate HI for each system behind, or just one per box? TH: Debatable. Presently one per box, not proxying for the host behind. BM: Next Q would have been, is this the proxy? AM: Is this in openhip? TH: Not yet, but it's in the approval cycle. There will be a draft too. AM: Great, openvpn is easy to dislike 5. Update on HIIT and InfraHIP's recent activities and future plans presented by Joakim Koskela (JK) -------------------------------- Questions: AM: The draft for TCP extensions should be revived. Unknown: Are there any Windows implementations of HIP? TH: There is OpenHIP support for WinXP, apparently works on Vista too. 6. Open Discussion ------------------- BM: Bob is working on moving HIP onto the standards track. ADs are looking at the HIPWG charter to address RFC5201 IESG concerns, and to advance BEET. The big concern in 5201 is crypto agility, there are some issues there. There will be a call for proposals on addressing crypto agility concerns without making the protocol too heavy. Please look at those issues. TH: Status of BEET? BM: Not in the IPSECME charter, can go in as an AD draft. There is review going on, without requiring a charter change in IPSECME, by AD sheparding. If it requires a HIPWG recharter, that can be done. TH: Congrats to HIPL for getting BEET into mainline Linux TS: Recommends HIPL not 'squatting' on a TCP option number in mainline Linux... that should be resolved TH: meeting closed.