Last Modified: 2004-11-02
Done | First version of the HIP basic mobility and multi-homing mechanism specification. | |
Done | First version of the HIP DNS resource record(s) specification. | |
Done | First version of the HIP basic rendezvous mechanism specification. | |
Dec 04 | WGLC on the HIP architecture specification | |
Jan 05 | Submit the HIP architecture specification to the IESG | |
Mar 05 | WG LC on the base protocol specification | |
Mar 05 | WG LC on the base protocol specification | |
Apr 05 | Complete the base protocol specification and submit it to the IESG for Experimental | |
Apr 05 | WG LC on the HIP basic mobility and multi-homing specification. | |
Apr 05 | WG LC on the basic HIP rendezvous mechanism specification. | |
May 05 | Submit the HIP DNS resource record(s) specification to the IESG for Experimental. | |
May 05 | Submit the HIP basic mobility and multihoming specification to the IESG for Experimental. | |
May 05 | Submit the basic HIP rendezvous mechanism specification to the IESG for Experimental. | |
May 05 | Recharter or close the WG. |
Minutes, HIP WG, 61st IETF HIP Meeting
1305 Status of Work- Chairs 1315 Architecture draft-ietf-hip-arch-00.txt
(currently under WGLC) 1335 Base
Specification 1355 DNS
Extensions 1410
Mobility and Multi-Homing 1430 Rendezvous Detailed
Discussions --Jan 05: submit HIP architecture to IESG --Apr 05: complete base spec and submit as experimental --May 05: dns,
mobility and multihoming and rendezvous to IESG
for experimental agenda bash -- no changes
Comments so far: Some general editorial comments and some clarifications were asked for. One substantial comment -- what is the correct term for ephemeral HIs -- anonymous ? -- private ? -- unpublished ? Currently unpublished is used in spec which may not be a completly accurate description of the intent of these HI's If you have a better naming option please submit the comments. Document next steps
Working Group Chair comment We have not received lots of comments but their seems to be lots of interest in this. Please read and comment. Open Issues in the Base Specification 2) Base Spec draft-ietf-hip-base-01.txt -- Petri Jokela Changes and open issues from 00.txt See issue tracker on hip4inter.net List
of closed issues Issue #46: 128 bit LSI's both 32 and 128 bit LSI's fgor v4 and v6 compatibility 128 bit lsi's for resolving HIT/IPv6 collisions LSI subnets still TBD HIT's changed to 128 bits Issue 48: remove BOS aand PAYLOAD packets not critical at this point so Bootstrapping and Payload packets will be defined in a later draft. Issue 39 removal of HIP state close/close-ack mesages added and closing and closed state added Issue 47 Make RSA mandatory algorithm changed mandatory implementation from DSA to RSA DSA is still recommended Transform algorithm change move from 3des to aes Make HIP SIGMA compliant I2: new HMAC TLV covering the whole packet R2: HMAC calculation also covers responders HOST_ID
List of open issues Issue 31 IANA allocations LSI 1.0.0.0/8 allocation 128 bit LSI prefix allocation Issue 37: notification data field usage Issue 49: Iana considerations needs to be wriiten Issue 50: remove appendix E Running HIP over IPV4 udp, this needs to be a sepaate draft no questions/comments on
the base spec doc in the
room please comment on the mailing list Open Issues in the DNS Specification 3) HIP dns extensions draft-ietf-hip-dns-00.txt -- Julien Laganier
goals 2 new dns RR's used by Hip nodes HIPHI for stroring a HIP nodes HI and/or HIT similar to IPSECKEY RR HIPRVS for storing a HIP nodes Rendezvous Servers FQDN or IP Addr
document changes -- Changed HIT storage to variable length, type and algorithim HIT's -- support for multiple RVS in same HIPRVS RR -- reuse most of the type values in IANA registries for IPSECKEY RR
-- Security considerations section
An open issues using multiple HI's and IP's What if FQDN maps to multiple HI's Each HI's maps to a particular set of IP addrs; Suggestion FQDN might map to multiples sub-FQDN's, each of them mapping to a flat set of HI's and IPs
A lively discussion of considering these
changes to DNS occured -- Discussion of DNS mapping host name to get ip address of host vs mapping to a provider of a service Pekka N: simplest if names resolve to single HI Dave: If we do this, we limit the applicability severely; we are losing the boundaries of a 'host'. Pekka N: does this simplification cause any harm? Bill: don't tell me how to run my DNS -- DNS is a mapping that can do this. Pekka N: Looks like DNS may well be a temporary arrangement. HI to IP Address mapping is problematic. Dave: difficult time getting required detail, but can't change meaning of domain name. HIP is experimental, so use that to allow for troubles. Pekka N: DNS experts say numbers of HIs per name are necessary. Don't know how to get HI to IP mapping in that case. Tim Shepard: DNS maps names to IP, have HIP ask the question. Tim wants HIP to be largely independant of the DNS. SSH has been useful for a long time without keys in DNS, why can't HIP be. Gonzalo: HIP query extension like that is RG material. Christian Huitema: Does this make a circular dependency? Bob M: Useful to know that a HIT/HI really is bound to the service you think it is, DNSSEC buys something. These RRs are a way to get the information into the DNS. Eric Nordmark: If you get multiple HIs and IPs, and don't know it's a host or a service. During initial exchange, if we get locators for that HI, then we're OK. Pekka N: If we get that, just make exchange and check for a valid responder HIT for one of the HIs that came back. Julien: Separate RRs or subtype? Dave: Subtyping is bad. Gonzalo: People love to have discussions, but details go away. Editors are complaining about lack of detail feedback. Open Issues in the Mobility and Multihoming Specification 4) mobility and multihoming extensions -- Pekka/Tom Henerson
goals --session persitence across multiple locations simultaneously(multi-homing) sequentially(mobility) addr familes v4/v6 transition) --address verification --locator chnage with/wthout rekeying --declaring a preferred address --announcing additional locators in base handshake --middlebox friendliness
non-goals --rendezvous and proxying --location privacy --multihoming with legacy hosts --transport layer issues mtu discovery, congestion control, qos ???: what did you mean by middle box friendliness? This is an attempt to allow middle boxes to snoop protocol and do the right thing. Did we get this right please comment
new updates SA's are paired not assymetric to avoid ambiguity when rekeying multihoming is restricted for failover now , it's not load balancing yet clarification on use of non-global addresse some additional clarifications needed -- implementation experience 3 implementations but not enough protocol use yet.
What’Äôs missing? policy considerations security analysis and considerations. issues in existing draft --parameter ordering for middlebox friendliness -- duplication of SPI values --are we doing enough for NAT traversal -- more analysis needed --multihoming design is probably not clean or understood enough next steps --informal middlebox design team/reviwers needed and resolve interactions with mobility and multihoming --need experimentation with real multihoming --security and policy sections need to be written ???: what is in mind for authentication with say a firewall. we need something like a registration protocol for this. some work in the RG on this. might need to send multiple registrations -- one for each middlebox device ???: It might be difficult to do this with low end nat boxes as these boxes in the low end are averse to ading more code. some work going on in other WG's on this as well. Open Issues in the Rendezvous Server Specification 6) rendezvous server draft-- Julienb Laganier Hip rendezvous extensions draft-ietf-hip-rvs-00.txt
Goal HIP nodes might frequently change it's ip addrs might maintatin rechability using it's rendezvous server
What changed? Femoved IP concealing extensions Added support for oportunistic initiators relaying I1 and r1 Add security and IANA Considerations Complete REDIRECT packet descriptions Some new header extensions new parameters: RVA_REQUEST RVA_rewply from, to, via_RVS See slides for descriptions
next steps Does the protocol need all these relaying redirect modes? Is the to paramter needed ? echo_reply is required anyway Should we split the current spec into redezvous service and hip registration with the rendezvous server Pekka N: It's too complicated and too many options make this too hard to achieve interoperability we need a tunnel rendezvous server to tunnel packes back to the real host need a simple rewrite of the packet maybe we should just rewrite instead of tunneling. possilby redirect should be split out. ???: Is it too early to talk about rewriting the packet -- what if your authenticationg packet headers we only relay hip packets ???: rewriting might be a problem for like ah ???: this is undefined how you'd run say tcp on top of hip -- need clarifcation that if you try this you might run into problems. Done with
agenda Reminder the research group is
meeting during fridays
session |