[Hipsec-rg] meeting minutes from HIP-RG meeting

[[e-mail] (Henderson, Thomas R)]

Please provide any revisions to the below minutes which
will be posted to the Proceedings before the deadline.
We'll also post copies of the slides.

Thanks to Andrew McGregor, Tim Shepard, and Julien
Laganier for note taking.

**************************************

Minutes of HIP-RG meeting, August 6, 2004. =20
(83 people signed pink sheets)

0.  Agenda bashing
- Move Jari Arkko to end of session

1.  HIP RG overview (Tom Henderson)

(see slides for presentation)

Tom:  any questions?... (none)

2.  HIP Native API (Julien Laganier)

Lars Eggert:  Why are you binding to a src interface rather than =
address?

Julien:  Ask Miika for motivation.

Kevin Fall:  Have you thought about running apps over a non-IP =
environment?  Will we have the transport to plug into this? =20

Julien:  Pseudoheaders in HIP use the HITs.

Joe Touch:  Binding to interfaces doesn't make sense.  Interfaces have =
multiple IP addresses.  A single host identity must be able to bind to a =
particular IP address, for policy reasons.

Tim Shepard:  What if no DNS?  Nervous about building in dependencies on =
DNS.

Julien:  use /etc/hosts.  Can fall back to opportunistic mode too.

Andrew McGregor:  Agree about not binding to an interface.  You may want =
to bind to a HIT and use a setsockopt() to associate a locator with it.

Kevin:  Thought of a better way to ask my previous question.  Can HIP =
run on other networks?

Julien:  haven't thought about this.  (no discussion)

??:  Why are you using DNS to bootstrap this system?  How to find the =
DNS server?  I think that using DNS is a bad idea.

More questions?   See http://hipl.hiit.fi/hipl/

3.  HIP over NATs (Martin Stiemerling)

-- main changes since last time-- added section on HIP-unaware NATs

Tim Shepard:  Suggest that you look at RFC 3056/3068 approach for 6-to-4 =
NATting as an approach for HIP NATs.  Use IPv4 anycast to traverse.  =
This approach is not HIP-specific.  Would be happy to point author to =
the relevant RFCs.

Tom:  Does this provide mechanism to learn your public address?

Tim:  Inside hosts just do IPv6.  Embedded in the /48 prefix is the IPv4 =
address.

4.  HIP and Rendezvous Servers (Lars Eggert)

-- Most significant change is location privacy ideas due to Marco =
Liebsch.

Lars:  Should we keep this draft together or split apart (maybe split =
the privacy concepts out)?  Draft is getting kind of big.

Julien:  In favor of splitting documents.

Andrew:  Observation:  Location privacy is about the only sane reason =
for using a NAT. =20

5.  Delegation (Mike Walfish)

- this is a position paper being presented at ACM Sigcomm in a few =
weeks.

Joe Touch:  Names resolve to delegates?  Aren't they really talking to =
the host?  If names resolve to delegates, are the delegates not the =
endpoint? The=20
indirection here has no real meaning.

Mike:  need to have delegation in the architecture..

Lars:  In your picture of cascading NATs, what if NAT translates the =
identity?

Hannes Tschofenig:  Look at the literature on this topic.

Mike:  Do you mean the MIDCOM stuff?

Hannes:  Yes, and ...

Melinda Shore:  the main problem with NAT is that it doesn't translate =
an address.  NATs don't have presence on the Internet ...

Mike:  we are advocating that we explicitly put NAT in the resolution =
step

Melinda:  decoupling service identifier helps a lot (better than port =
numbers), so this would be a positive step.

Hannes:  Security problems of NAT firewall signaling.  Since there is a =
separate protocol for this, it might cause security problems.

Mike:  We have a tech report coming out in December that is explicitly =
concerned with security.

Julien:  Why not use application IDs instead of service level IDs?  Why =
do you have two?

Mike:  Might be misunderstanding? (Yes).  Proposing that same resolution =
system use to serve both name spaces.

Kevin Fall:  IP addresses and names went hierarchical in the 1980s.  Why =
flat now?  Is this overkill? =20

Mike:  So can have persistence irrespective of moves.

Kevin:  Hierarchical spaces easier to administer.

Mike:  Granted.  But I don't think that humans should administer this.
Kevin:  Indirection is presently useful.  Your indirection point is your =
mail server and the identifier is the address. The time needed for =
delivery is greater than for I3 (...)

6.  i3 project (Karthik Lakshminarayanan)

Jari Arkko:  What about security aspects of this?  Do you have =
assumption of security between a host and an I3 server

Karthik:  eavesdropping in i3 is easy.  For this an other reasons, we =
need to secure the infrastructure.  There are a number of crypto =
primitives in a project known as secure i3-- written up in a UCB =
Technical Report.  The ID's is derived from the key, so you can =
trivially establish SA (Id is a hash of the key).

6.  Hi3 architecture (HIP and secure-i3) (Jari Arkko)

Lars:  Hidden IP addresses don't only provide location privacy-- they =
protect attackers

Jari:  Yes, but do you care as much if you are able to deflect attacks?

Joe:  Previous speaker pointed out DataRouter project.  In that project, =
we provide a way to implement, via IP options, strings and string =
substitution rules.  Gives you an overlay with the performance of the =
network layer.  I'll send a pointer to the list.

(editor's note:  see http://www.isi.edu/touch/pubs/iwan2003/)

Karthik:  Why do you need middleboxes when you have i3?

Jari:  May be possible to combine the two.

Hannes:  I like this I-D because it reuses HIP and applies it to =
overlays
You can see from some papers that P2P folkd try to reuse HIP work so I =
think
you're on the right track.  Interesting thing: New Internet architecture =
looks a lot like MPLS-type things.=20

George Jones:  I'm putting my black hat on now.  Thinking of how to =
break this. i) if you are going through middleboxes, these are =
opportunities for attack
ii) you are offloading DoS protection onto the core of the network.  Are =
they going to want to pay for and maintain such infrastructure?  Some of =
these solutions just seem to be shifting the problem around.

Jari:  i) the middleboxes functions can be distributed to lower the =
impact of attack on a single one

Hannes:  (in support of Jari) this improves the situation without trying =
to solve all problems. The puzzle-cookie can provide some resilience, =
and I3 also by hiding IP addresses.

Martin:  ?  (something about NAT)

Tom (chair):  We've had three presentations now on richer architecture =
concepts that make more use of overlays, indirection, privacy.  Is the =
RG interested in prioritizing this work?  Or should other issues (like =
APIs and NATs) take priority.  (Some show of hands in support of =
focusing on these architectural issues now).

7. Open mike

Aaron Falk:  Speaking of applications, it may be useful to talk to the =
SIP people, who are using IP addresses to identify infrastructure, and =
see if HIP might be of use to them.

Tom:  Yes, have had some discussions this week-- would be interesting to =
see what aspects of HIP functionality that SIP has already implemented, =
and what of HIP that SIP would use if HIP service were available.

Tom (chair):  Any interest in participating in a HIP research workshop =
prior to next IETF meeting (on Saturday)?  (about 20-30 hands).  =
Interest in presenting? (maybe 5-8 hands)

Joe:  Tacking onto IETF is generally bad because the week is very long =
already.

Tim, Andrew, others?:  Yes, but many of us have travel budgets and time =
constraints that make it convenient.

Avri Doria:  We are also talking about such things in our RG and might =
want to consider coordinating these type of things.