Subject: [Hipsec] Raw notes from the HIP meeting

From: Pekka Nikander <[email-masked]>
Date: Thu, 23 Mar 2006 10:07:20 -0600

Notes from the HIP meeting on Thursday, Mar 23 at 9am.  Aplogies for  
typos.

0900 Status and agenda bash – Chairs

Status of the working.  Architecture draft in RFC editor queue.  RFC  
4423.  HIP-based and HIP-esp post WG LC.

[Pekka Nikander:] Security area reviewer Charlie Kaufman, promised to  
do Bellowin-Rescorla analysis.

[Gonzalo:] Another open issue.  KHI / ORCHID pending on Internet  
area.  Talk to ADs.

dns, rvs, registration ready to go, waiting for the base spec

mobility and multi-homing in WG LC.

Base spec -04 to -05.  Clarifications, open issues: Bellovin-Resrocla  
analysis, editorial.

ESP -01 to -02.  Rekeying updated.  Open issues Bellovin-Rescorla  
analysis.

Re-chartering issues:
- NAT traversal in HIP
- interface HIP to legacy and new applications

draft-schmitt-hip-nat-00

[Miika:] Goal to have a implementable draft, focus on clients behind  
a NAT.

Goal to have practical that works with existing NATs.  Implementation  
work going on. Two implementations being completed.  NEC Germany  
working on one, HIIT in Finland on another one.

Concenctrate on the case with a client behind a NAT, future version  
with a server behind a NAT.  Only little about firewalls.  If there  
is a firewall, there must be firewall policies in place.

Extensions for both base exchange and mobility and multi-homing.   
Perform NAT detection with a separate protocol and not include that  
functionality in the HIP control packets.  Better compatibility with  
future NAT boxes taht can be controlled by end-hosts (behave?)   
Drawback is extra latency caused by extra roundtrips.

Both HIP control and ESP packets carried in UDP.  HIP control packet  
format.  No need to have a checksum in the HIP header since that is  
in the UDP header; therefore a zero HIP checksum.  Separate keep- 
alive format, uses UPDATE packets, see the draft.

ESP encapsulation compatible with RFC3948.  Both data format and keep- 
alive.

Base exchange through a NAT.  I1 punches a hole into the NAT, the  
rest of the HIP traffic flow over that.  However, it is possible that  
I2 source port is different from I1 source port.

Port numbers, separate ports for control and data.

[Andrew:] Did you check with the IANA?  [Answer:] No, but we checked  
they are unallocated.

Mobility.  Four use cases:
1. Host moves from behind a NAT into a public network
2. Host moves behind the same NAT
3. Host moves from behind one NAT into another NATted network
4. Host mvoes from a public network to a NATted network

Hosts must detect if there is a NAT and start using UDP encapsulation  
if needed.  Note that port numbers can be forged or there can be  
reflection or replay attacks.

Multihoming.  Not much in the draft; more complicated.  For example  
one interface may be behind a NAT andother in a public network.   
Could be asymmetric routes.  SPI number used to distinquish between  
routes???

[Erik Nordmark:] Multiple host itself interfaces vs. the destination  
has multiple addresses.  Effectively creating two mappins in your NAT.

[Miika:] Firewall configuration.  Firewall policies if want to allow  
traffic through.  Can use UDP connection tracking.

Open issues:

Issue 1. Share the control/data UDP port numbers with IKE (RFC 3947 /  
3948)

[Pekka Nikander:]

[Andrew McGregor:]  Have both for the time being.  Would be helpful.   
Explain both scenarios.  Two methods have different configurations in  
the firewall.

[Lars Eggert:] Not sure OK to re-use the existing UDP port.

[Andrew:]  Existing implementations are going to be OK.

[Mark:] What is current IANA policy for those 256 preserved SPIs.   
Good indication w.r.t how much damage this could do.

[Mark:] Keepalives?  [Answer:] Yes

[Answer:] IANA policy.  Requires publication of another RFC.

[Mark:]  Also a survey of implementations needed.

Issue 3: Server behind the NAT.

Not defined yet.  Try to avoid triangular routing by UDP hole  
punching, works only with p2p friendly NATs.  Fallback triangular  
routing with TURN.

[Gonzalo:] Go to check TURN details in behave working group if  
reflection is allowed.

Design alternatives: ICE, subset of ICE

[Gonzalo:] ICE is offer/answer oriented.  I think you cannot directly  
reuse ICE.

Need to check if TURN is really an option.  Open editorial issues.   
Separate draft or not?  WG or RG work?  In any case, should work out  
how client and server behind a NAT are compatible.

[Andrew:] Without a third party both client and server behind a NAT  
not possible.  Depends on the behaviour of the particular NAT.

[Lars:] Julien Laganier states in jabber that two drafts would be  
overhead.

[Gonzalo:] Server reachability behind a NAT is a quite a general problem

Issue 4:  Breaks the ucrrent simple rendezvous server

Current rendezvous is relaying only I1.  R1 will confuse some NATs,  
causing R1 to be dropped.  Allow rvs to relay R1's, too, when  
encapsulated in UDP.

[Andrew:]  Which works but it is posisble that soma NATs will not  
drop R1.  Perhaps needs a few bits of information to figure out the  
two cases.

Issue 5: LOCATOR.  What kind of addresses in the LOCATOR parameter.   
Strawman proposal: even send the private address.  Doesn't require  
any changes in the mobility implemntation.  Privacy problems.  Detect  
the public address and send those.  No privacy problems, but not sure  
of the benefit.  Alternative three.  Filter out private addresses and  
punch a hole in the NAT.

[Andrew:] Rely on mobility implementation to use the addresses from  
the outer header.  [Answer:] Yes [Andrews:] Experiment.  You can't  
use private addresses for anything.  No use in sending them.

[Erik:] You don't always know if you have a private address or not.   
Question:  How to filter out private addresses.  How about a host  
that is also behind the same NAT.

Issue 6:  Inner addresses as IPv4 / LSI

Issue 7: Editorial notes

Generalise the text and reduce the number of details.

Issue 8: ESP data channel reactivation upon handovers

Server does not know to which SA the keepalive is related to.  Port  
numbers for the ESP data channels.

[Pekka:] Consequences of usign the same port number.

Issue 9:  Hairpin translation

Both hosts behind the same NAT, detect the NAT but don't know that's  
the same NAT.  Solution:  First try to send packets with UDP  
encapsulation.

[Pekka:] Reasons why you always want first to send control packets  
without UDP encapsulation.

---------------------

Rechartering

[Gonzalo:] Proposal for two new WG items.  Scope these in a way that  
are acceptable.

Drafts relevant to NAts (see slide).   Different scope of different  
drafts.  WG charter to allow wide scale experimentation of HIP.   
Scope of the WG not to be extended.  Only concrete things that allow  
experimentation and not go to research work.

Documents relevant to legacy applications.  Not to develop an API but  
analyse how to use existing APIs when you have HIP below.   
Recommendations to implemntors.

Open mikes:

[Andrei:]  Native API draft?  [G:]  We don't work on APIs in that  
sense.  At least not in its original form.

[Andrew:]  Native API document should be but through as information  
in research group or individual.  Not right for the HIP WG.  UDP  
document we just talked about should be a WG document.  Enough time  
to get some actual implementation expence.  Find out which techniques  
work and what are consequences.  May even have consquences on  
encapsulation.  Will take a little while.

[David:]  Lays out the issues.  Your uggestion?

[Andrew:]  The UDP document is nearly there but we want to have some  
implementation experience.  Feed the results first to the UDP draft  
before publishing it

[D]  Want to avoid open ended draft that would need a long wait.

[G] Have alook at the behave WG documents

[Mark Townsley] On API draft, it is not so true that the IETF does  
not do APIs.

[D] We've been here for quite long time.  Legacy app doc enough.

[Mark] Find out if you need it or not.

[Geoff huston:]  If you need an API, do it.  If API is necessary, if  
there is information taht oculd be transmitted up or down to make  
apps to work _well_ with HIP, do it.

[Yu] Support considering the API.  In BTNS we are in the problem of  
rethinking the APIs.  If we just do an interface it is hard for  
actual protocols to use it.  Hoping that HIP doesn't make the same  
mistake than IPsec

Comment in jabber:  IETF does API but not for interoperation.

[D] Consensus call.  API document will be taken to the WG, to be  
verified on the list.

[Miika]  Additional working items?  BOS packet, re-activate the work  
on BOS.  Makes interoperability testing easier.  HIP bootstrap stuff  
is very easy.  Another issue, maybe for research group.  M&M defines  
the basic stuff, but should consider more advanced stuff.

[Pekka:] Multi-homing and mobility.  Should include everything needed  
for more advanced stuff without really specifying how to do it.

[Lars:] Question on HIP NAT.

[G] Consensus on the first two items, decided to add the native API too.

[Miika:]  SHIM6

[Pekka:] Dave Thaler in SHIM6 askign for a document on HIP/SHIM6/MIP

[Erik:] SHIM6 people working with SHIM6 and Mobile IP; don't know  
what people will say about HIP.
Clarification on the packet formats.

[Geoff Huston:]  SHIM6 proto document in WG LC.  Interactions with  
Mobile IPv6 and only that, only compatibility issues.  Don't foresee  
any issues.  SHIM6 will not in its charter have anything to do with  
HIP.  In terms of compatability there is nothing in the charter, may  
more grativate to HIP WG than SHIM6 WG.

[Andrew:]  Upgrate IPv6 to SHIM6 and then SHIM6 upgrade to HIP.   
Research item.  Would require rechartering.

[D]  If the IETF community would decide to turn SHIM6 to HIP, then we  
could do it, but that is far in the future.

[Geoff]  IETF thought police.  SHIM6 locator agility, not mobility.

[D]  Good discussion.  Done here.  See you in montreal.

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Thu, 23 Mar 2006 18:25:21 +0100

Most of the slides are not on the webpage. 
Could you please upload them now. 

Ciao
Hannes

> -----Ursprüngliche Nachricht-----
> Von: Pekka Nikander [mailto:[email-masked]] 
> Gesendet: Donnerstag, 23. März 2006 10:07
> An: Gonzalo Camarillo; David Ward
> Cc: HIP
> Betreff: [Hipsec] Raw notes from the HIP meeting
> 
> 0900 Status and agenda bash - Chairs
>