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
1305 Status of Work- Chairs
draft-ietf-hip-arch-00.txt (currently under WGLC)
1335 Base Specification
1355 DNS Extensions
1410 Mobility and Multi-Homing
--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
-- 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 188.8.131.52/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
3) HIP dns extensions draft-ietf-hip-dns-00.txt -- Julien Laganier
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
-- 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.
4) mobility and multihoming extensions -- Pekka/Tom Henerson
--session persitence across multiple locations
addr familes v4/v6 transition)
--locator chnage with/wthout rekeying
--declaring a preferred address
--announcing additional locators in base handshake
--rendezvous and proxying
--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
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.
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
--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
HIP nodes might frequently change it's ip addrs
might maintatin rechability using it's rendezvous server
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
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