[Hipsec] Please check for correctness: transcription of HIP BOF discussions

[[e-mail] (Pekka Nikander)]

This is a multi-part message in MIME format.
--------------000900090405020100090605
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Please find enclosed a draft for the transcription
of the HIP BOF discussions on Monday.  Many thanks
to Spencer Dawkins, John Colins and Eva Gustafsson,
whose notes the transcript is based on.

PLEASE CHECK that what I have written down matches
with what you intended to say.  If there is anything
that you want to change, please let me know as soon
as possible, preferably before the end of this week.
It would be nice if you could acknowledge that you have
checked your sayings even if there is nothing to correct.

There is also a few unidentifier speakers.  If you recognize
who they most probably have been, please let me know and I
will try to contact them.

If somebody can forward this to Nico Williams, Tom Petch,
and Melinda Shore, please do so, since I don't have their
e-mail addresses.

Once I have an accurate transcript, I will produce a set
of minutes that summarize the discussion.

--Pekka Nikander


--------------000900090405020100090605
Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0";
 name="discussion.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="discussion.txt"

Pekka did a nice overview of HIP. He pointed out that HIP doesn't map
cleanly into any IETF area, but it could become the next "waist" of
the IP protocol stack. HIP uses ESP in transport mode, has a four-way
handshake for association setup, and is DoS-resistent - R1 packet is
cryptographic, but is precomputed.

Pekka also pointed out that the mobility/multihoming drafts are much
less mature than the base protoco spec, etc.

Keith Moore: HIP is nice, but being oversold.  It has a lot of
  brilliant ideas, but it doesn't solve all of the claimed problems,
  it helps to solve them.  You need to clarify what HIP does & doesn't.

Pekka Nikander: I agree.  I don't remember what I said during the
  talk, but if I said that HIP "solves" the problems, it was wrong.  HIP
  provides mechanisms to solve these problems, but as it stands now, it
  does not "completely" solve the problems.

  
Jim Bound: Too much overlap between protocol specification and
  implementation description in the documents - this needs to be
  removed before entry into standards track.  How to rebuild our
  stacks it not your business.  What do you want in terms of
  standards?

Pekka Nikander: We have been trying to move implementation level
  issues to appendices.  It is well possible that not all has been
  moved.  If there are still sections that talk too much about
  implementation, they need to be moved to an appendix, too.

(Nods from ADs)

David Ward: Please note, too, that the architecture document is
  headed towards informational RFC, and informational documents may
  discuss implementation issues.


Erik Nordmark: Do we know about claimed IPRs on this? 

Pekka Nikander: We don't know for sure.  There may be IPR claimed on
  the puzzle.  However, given how the current puzzle implementation
  is, my personal belief is that there shouldn't be any.  It is also
  possible that there are IPRs on the Diffie-Hellman MODP groups, but
  based on discussions at the IPsec WG it does not seem to be a
  problem.
  
Eric Fleischman: Bob Moscowitz says he won't patent his
  contributions.   Neither does Boeing.

Bill Sommerfeld: Given my understanding of the patent law, it isn't
  sufficient to say there are no IPR claims. 

Eric Fleischman: All I am saying is that Bob Moskowitz does not have
  any IPR on this.

Margaret Wasserman: If this becomes a working group, we need to look
  at the IPR issues then.

Perry Metzger: Why WG for experimental documents?  What is the policy
  for experimental documents?

Thomas Narten: Currently the IPR requirements are for standards-track
  documents, not experimental.  However, there are new policies in
  the IETF with respect to IPR and experimental track documents.
  Hence, the IPR status need to be declared for all documents.

David Ward:  We clearly need to investigate whethere there are IPRs
  or not.

  
Eric Rescola: How does HIP play with IPsec?  Is the assumption that
  you want to use IKE and IPsec over the top of HIP? 
  
Andrew McGregor: Well, you could do both, but then you would end up
  encryptiong twice.  Or, you could HIP to establish some SAs and IKE
  to other ones.  Depending on implementation, you could use policies
  to control this.

Niko Williams: Does server need to do public key
  operations before reverse routability verification? What is the
  computational load on server?  How about DNSsec or certificates?

Pekka Nikander:  From our point of view, I would say that HIP is not
  so much of IPsec.  Bob Moskowitz assumed that people would be doing
  ESP anyway, so the default is to use ESP.  However, architecturally
  HIP could be implemented without any IPSec at all.  The exact way
  of doing that is just not specified as of now.

  What comes to return routability and server load, the R1 packet is
  precomputed.  Hence, the server isn't vulnerable to DoS attacks at
  that point. 

  We deliberately left DNSsec and certificates out of the scope for
  now.  They were there before, but their usage depends so much on
  what do you want to use HIP for that it is better to scope them
  out. 
  
  
(?):  Have you tested mobility and renumbering?

Pekka Nikander:  Yes, there will be demo of this in a few minutes.  


Steve Kent: This is a solution looking for a problem. IPsec is much
  more than just ESP.  Hence, you're not doing IPSec, you're just
  doing ESP.

Pekka Nikander:  You can say that we are not doing IPsec but only ESP
  if you want to express it in that way.  What coems to the problem,
  there seems to be a need to separate identifiers from IP
  addresses.  This is one possible answer to that problem, and we
  need to understand better the properties of this.

Steve Kent:  A solution must fit within prespecified constraints, and
  I have haven't heard any of such constraings.

Perry Metzger: Don't break a butterfly on the wheel.  This is an
  experiment.  We need more of them.  I think this is a great idea.
  For once we have a bunch of people going out doing something that
  may not provide all answers at once.

Eric Fleischman: We tried doing requirements first last time; that's
  why we're not a WG now!

Keith Moore: It is more correct to say that identifier/location
  combination is a design compromise, not merely wrong.

Steve Kent: A question to the ADs.  If the intent is to create an
  experimental group, why is this being proposed for IETF, why not
  IRTF?

Thomas Narten:  IRTF is research, IETF is engineering. We are trying
  to engineer bits on the wire. 

Steve Kent: For what I have heard, we want to play with this until we
  know what it's good for.  Engineering is about solving problems, not
  playing with something to see if it's useful.

Margaret Wasserman: In materials engineering, you may have a new
  material and it is still engineering to see whether it best fits a
  problem.  We do know some of the problems we are working on. We
  already have implementations. The idea is to see how this fits
  within the rest of the system This isn't strictly an experiment.

Pekka Nikander cut the discussion short to continue with the agenda.
  

20 min  Demo of current implementations          Demo team
==========================================================
          - HIP base exchange
          - HIP mobility between IPv4 and IPv6
          - HIP based IPv4/IPv6 API bridging

Keith Moore: I want to point out that this is not so wonderful as it
  might seem.  It doesn't live up to the claims being made for
  HIP.  What if both sides move at once?  I challenge you to work
  with both hosts moving concurrently, to create a demo that shows
  that this is a practical solution, not a toy.

Jeff Ahrenholtz(?):  This is experimental, this isn't complete.

Keith Moore:  So there are still probably issues that need to be
  looked at.  This is interesting technology but not complete.

David Ward: Of course.  That is why we want to do a WG on this.  We
  just want to avoid working in the dark.

  
(Other presentations)

* 50 min  Charter discussion                       All
======================================================

Tim Shepard: I attended the earlier HIP BOFs.  Very soon after the
  second HIP BOF, I was not in favour of forming a HIP WG.  Today, I
  use SSH instead of IPsec as my VPN solution.  SSH was a protocol
  solving an as yet not understood problem.  I hope that HIP does get
  there.  If we look at engineering in the world, there _are_ a lot of
  things that are done bottom up, and that is wonderful.  I hope that
  the development of HIP can proceed like this, and I am not convinced
  that an IETF WG can help.  I am not sure that bringing HIP to the
  IETF is the right thing.  If SSH had been brought into the IETF in
  the beginning, it might not be as valuable as it is today.  I'm not
  actually sure what is the correct thing.  I am ambivalent.

James Kempf:  You should get rid of the proposed charter items 9 &
  10 (Implementation report & MIB), they are standardization items and
  shouldn't be part of experimental.  I think that the biggest problem
  is the rendezvous server.  There are other proposals around for
  separating identifiers and locations without cryptographic keys.
  They need to be also considered.  We need to understand if a
  cryptographic name space has any additional value.

David Ward: The intention of putting up an implementation report is
  to separate implementation techniques from the specification.

Erik Nordmark:  It is good to continue to explore HIP, and a WG is a
  good way to do this.  One is issue is IPv4 by itself, other concern
  is NAT.  It is operationally hard to make a robust solution as all
  NAT implementations are different.  That may make it hard to focus.

Pekka Nikander: There are two approaches to the NAT problem.  One is
  to base the solution on existing mechanisms, meaning UDP
  encapsulation.  The other is to enhance NATs, i.e., to teach NATs
  to understand HIP.  The current thinking is in the favour of the
  latter. 

Keith Moore: This is bottom-up architecture.  That's the wrong way to
  do architecture. We need top-down architecture before we deploy
  widely.  The search mechanism (Charter item 7) isn't optional, it's
  critical.  I would make it number 1 on the list.  Need to look at
  wide range of interactions, for example, MTU changes when we move
  from v4 to v6. Probably need to do base spec last, including what
  we've learned from working on other specs.

Pekka Nikander:  The current plan is to complete the base spec first,
  then get operational experience, and then revise the base spec if
  needed. 

Perry Metzger: SSH was widely deployed before coming to IETF - the
  IETF value-add was SSHv2.  The protocol originally had some serious
  flaws.  HIP could be the same way.  It is important for HIP to be
  brought to the IETF.  It needs the exposure to a wide number of
  people so that it gains from the exposure and the protocol is
  improved.  We need to give the WG a chance to come up with HIPv2.

Bob Hinden: A WG for Experimental docs just seems wrong, wrt. IESG
  overload.  The deliverables look like charter items for
  standards-track documents - no cycles included.  I would like to
  see something that shows what is the result of the experiment.

Eric Fleishman: We need to add the v4/v6 transition mechanisms to
  charter list. In general, the IETF doesn't do architecture well and
  architecutral work is less appreciated.  This is architecture, but
  other people are starting to solve the same problem in piecemeal
  fashion - even worse than us!  I value HIP as giving the IETF a
  possibly more architecturally complete solution than the more
  piecemal approaches elsewhere.  HIP is giving the to IETF a
  possibility to consider a broader architectural solution.

Melinda Shore: The concept of exploratory WGs is under discussion (Ted
  Hardie draft, etc). This would fit in there.  NAT traversal is
  actually several problems that have never been decomposed
  appropriately at IETF, and name spaces is only one of them. Expect
  problems with directory, reachability, etc.  Making NAT HIP aware
  do not solve these problems.

Harald Alvestrand: If the IESG is overworked, then chartering or not
  chartering HIP not going to change that.  HIP won't break IESG's
  back, and it could help IETF later. Decide if this experiment is in
  the best interest of the Internet; in my opinion it is.  If so,
  we'll need to make it happen.

Spencer Dawkins:  APPS view of HIP is needed soon, to avoid late
  suprises. We want to have the applications guideline in the
  charter. 

Gabriel Montenegro: I would like to speak in favour of the WG, but the
  charter obviously needs some more hacking.  Items 6 & 7 (rendezvous
  and proxy servers & search mechanism) need more work and may be
  better done in research.  Personally, I would not worry about
  modifying NAT boxes but just assume they are there and workaround
  them.  My advice is to also create an IRTF research group to have a
  look at some of the issues.  At the working group side, should also
  be a document as a guidline of how to join the experiment.

Erik Nordmark: Should IKE interactions be considered? 

Pekka Nikander:  I am not sure.  We have the MOBIKE BoF later, and it
  addresses some (but not all) of the issues from the IKE point of
  view. 

Erik Nordmark: But what if you use ESP, use HIP to rehome your
  packets, and simultaneously want to use IKE instead of HIP to create
  the security associations?

David Ward:  If this becomes a working group, we apparently need to
  address this issue.

Elliott Lear: The NSRG research group at the IRTF didn't get far in
  this space. Perhaps the charter should be expanded to include MAST,
  NOID, etc?  It also seems like some charter areas aren't individual
  work items - they are too broad.

Tony Hain: Ignore NAT traversal unless you're doing IPv6. Look at
  infrastructure problems - that's the hard part - DNS, proxies,
  rendezvouz servers, etc.  They are what needs experimentation.
  Lots of work fails because of infrastructure issues.

Tom Petch: To the naive, it looks like the DNS is the crux of the
  problem. DNS is right answer but is perceived as useless to solve
  this problem. We need to bite this bullet now.

Steve Kent: You need to do a list of problems right up front.  Work
  item number zero should be a list of problems you are tackling.  Are
  you doing experiments or testing?

Margaret Wasserman: The current identity/locator overlap is a property
  of IP addresses, not inherently evil.  We need a scalable way of
  life after the split.  Don't throw all the experiments in a room and
  expect them to work things out.  Apparently we will eventually need
  something like the DHTs to be able to look up identifiers.

Erik Nordmark: There are overlapping conversations, and we need them.
  It is good to have these guys in one room. 

Spencer Dawkins: Yes, but don't put them all in THIS room - HIP is
  focused and already underway.

Margaret Wasserman: We're trying to build a taller tower. We don't do
  that by putting everything in one tower and hoping it fits and turns
  out to be taller.  In other words, we should not be put everything
  in the same room and expect to get a good outcome.  

Thomas Narten: Why a working group now? 

Pekka Nikander: We have been working on the base protocol for last two
  years.  It would now really benefit from a wider review.
  Additionally, we need to focus on the infrastructure requirements,
  and we don't have that expertise in the current HIP community.
  Creating a working group is one way to get a wider review and
  invite people with wider experience to take part.

David Ward:  We have reached the point where the initial work has
  uncovered some interesting problems and potential paths.  We need
  to finalize the specs we are working ong, and build interoperable
  solutions.   

Pekka Nikander:  We need a widely implemented experimentation to get
  operational experience.

Thomas Narten: HIP requires upgrades at both ends of an association. Is
  this deployable?  Is it deployable from the experimental work point
  of view?  How about longer term look, as a wider solution?  We need
  to consider these at the working group, if one is formed.

David Ward: There is no need for a Internet flag day for HIP, of
  course.

Thomas Narten: Can you prioritize charter items? 

John Loughney:  Everything beyond base spec is moving beyond
  experiment.  Need a crisp charter for experiments.  NAT traversal, for
  example, not needed for experiments. 
Pekka Nikander: Yes, we need to prioritize, but the base spec is not
  quite enough.
John Loughney: Ok, "Core set of what's needed" may
  be more than the base spec alone. 

Thomas Narten: The suggestion of  "DNS interaction" too vague. 
  Speaking about using HIP to dynamically update DNS, we need to
  check with the DNS WG.

Spencer Dawkins: Items needing wider community review can be
  mentioned in the charter without being chartered deliverables at
  this time.

Tim Shephard: What is the "minimal set?" Probably first three proposed
  items, plus a report on what the experiment taught us. Wait a year
  to add more deliverables - this is realistic.

Keith Moore: How can "minimal set" not be already done, if you have
  interoperating implementations now?  I am concernted that if you
  exclude important isssues, you need to work on all aspects
  together. 

Bill Sommerfeld: Is this technology incrementally deployable? If not,
  what changes does it need? You can't boil the ocean.

Margaret Wasserman: But IPv6 isn't incrementally deployable, either.
  Before we can have a question of incremental deployability, we need
  to decide what what we are talking about.

(The discussion came to end.)

10 min  Summary and next steps                   Chairs 
=======================================================

The chairs posed a number of questions:

A. Is this an interesting technical problem to pursue in the IETF? 
------------------------------------------------------------------
  room hands were "yes".

B. Do we have enough of additional people that would participate?
-----------------------------------------------------------------

B.1. Security? 3 hands raised (Bill Sommerfeld, Perry Metzger, unidentified)
--------------
  
B.2. DNS? no hands, but
---------

Randy Bush:  The needed DNS RR is trivial.

Thomas Narten: Need to get help from DNS WG.

B.3. Applications: No hands, but the appsarea meeting was taking place
------------------  at the same time.

B.4. Routing?  3 or 4 hands, depending what "HIP and routing means"
------------

Thomas Narten:  What do you mean with routing?
Margaret Wasserman: I asked the chairs to ask these questions, so
  that we get some cross area expertise.  

C. Do we have enough information to decide about a WG?
------------------------------------------------------

Randy Bush:  I am trying to understand how this relates to the work
  out of multi6.  I am not sure I understand the space yet, and what
  we can achieve here with a separate working group, and whether it
  would be useful?  

(?): The deployment piece that needs work is the secure updating of
  the infrastructure.

Keith Moore: I think that it is unfortunate that the applications
  people are not here.  They are the people who need broader view to
  finalise the charter.

Margaret Wasserman: All WG proposals get sent out for two weeks
  anyway.

The room hands was "yes", we do have enough of information.

D. Should we have a working group?
----------------------------------

Randy Bush: How this relates to NOID.

Margaret Wasserman:  We need to identify willingness to work here.

David Ward: We have managed to bash the charter so much that we need
  to have a charter discussion at the list anyway.
  
Tony Hain: My concern is that some of the  key pieces of the problem
  (infrastructure) have no volunteers. 

The room hands were "yes", based on successful charter discussions.

--------------000900090405020100090605--