Subject: [mobile-ip] IETF 50 - WG meeting minutes

From: [email-masked]
Date: Tue, 3 Apr 2001 23:39:04 -0500

Thanks to David Frascone for providing the meeting minutes of the
Mobile IP WG meeting at IETF50.

Thursday, March 22nd 2001 - 9:00 AM - 11.30 AM
----------------------------------------------

Basavaraj:
 >>	Agenda bashing:
	Modifications to the published agenda. Steve Glass unable to
	make it to this meeting.

	WG mailing list has been moved to a new server hosted by
	Sun. Archives are in the process of being transferred. Steve
	Glass has agreed to administer the list.

 >>	WG Doc status:
	New RFCs: 2034 (Obsoletes 2344) - Reverse Tunneling
	RFC 2035 Vendor specific extensions

	Drafts: mobileip-ipv6.  Blocked by IESG for security concerns.
	2002bis passed last call.  
	mobileip-gnaie - In IESG bin.

	Drafts in Limbo:
	mobileip-mier.

	Drafts that have completed last call:

		mobileip-optim
		reg-tunnel
		3gwireless-ext
	
	Drafts going to WG last call
		mobileip-key-aaa

	New WG documents
		glass-mobileip-reg-revok
		mobileip-lowlatency-handoffs-v4
		mobileip-fast-mipv6

 >>	Milestone Review

 >>	IESG Security concerns with MIPv6
	   Thomas Narten has sent out the IESG statement to the Mobile
	   IP mailing list which notes the issues identified w.r.t
	   security for the Mobile IPv6 spec.

9:14 - Jeff Schiller - Security and Mobile IPv6
------------------------------------------------

       Discussed the security issues from the perspective of
       scalability and the way IPSec is used in Mobile IP.

	How can we tell the difference between legitimate updates and
	attackers.

	IPSEC/AH?  
		It's an authentication protocol.  Can't it be used?
		Bottom line:  IPSEC is not a good fit for a situation
			where you want to protect some packets, but not
			all packets.
		IPSEC has a policy database to determine whether to send
		the packet encrypted or authenticated.  It's an all or 
		nothing type of approach.

		Other bad things with IPSEC:
			KEY negotiation requires several handshakes
			State
			No protection against man in the middle
				Requires PKI based on IP addresses
				And, it is not ready now . . . 
			No telling how long it will take to build
			a PKI architecture.
			
		IPSEC is used today to build VPNs.  In them, the admins
		usually set up a private PKI.  But, how do you do a PKI
		on the scale of the internet?

	Minimal Requirements for Security:

		No security exposures beyond today's IPv4
			But, why not do it better?
		
		Man in the middle attack "ok" if launched by an attacker
		in the path.
			Protecting against this is very hard.
			We eventually have to solve this problem when
			wireless takes off.

	PBK: One approach

		Purpose Built Keys.
		End point creates public key pair and EID.
		EID is hash of public key.
			Fixed length, reasonably short.
		
		Send the EID to the correspondent node.
		Correspondent node ACKs.  
		EIDs and keys change to provide privacy

		Once EIDs are known, then you can authenticate
		any packet you want by signing the update with
		the private key, and transmitting the public key
		in the update.  Since the EID has already been
		sent, then the binding update can be verified, and
		the EID can be checked by hashing the public key.

	HIP (Host Identity)
		Similar in ways to PBK.
		Designed to solve a more broad problem.
		Is an architectural shift.
		Can be made to solve the binding update. . . 

	Security AD hat on:
		No solution is particularly favored.
		Security requirements must be met.
		Punting security is not an option.

	IESG position:
		See AD position :)

For the extended debate and questions, please look at section A1 of
these minutes.

Connectathon Report:
---------------------

Alper Yegin:

	What Connectathon is . . . 

	14 mobile ip participants
		9 ipv6
		6 mobileip v4
		3 test suites for v6
		1 suite for v4
	IPv6
		8 correspondent nodes
		6 HAs
		4 nodes
	IPv4
		6 agents
		3 nodes

	Observations:  Specifications on movement detection need to be
		looked at.  Different interfaces of the same router
		can have the same MAC address, therefore some
		link-local address. 

		Sending Binding Update Acknowledgment.  What if the COA was
		invalid or multicast or unspecified.

		HA address discovery.  We don't need to send the home
address
		since it's the same as the destination address.

	Someone: There was an agreement on the list to remove that . . 

		Timing issues with BUs - can be fixed in implementations.

		ICMPs can delete binding cache (destinations unreachable)
		Attackers can forge these, and delete all the binding cache
		entries.

		Deregistering of Care-Of-Address.  

Carl Williams:

	Only had one participant implement IPv4 route optimization.

	Observations:  Might need a blurb that the FA may check the
existence
	of the MN_HA Auth extension.

	FA could override an error created by the HA. if the FA_HA authenti-
	cation is invalid, and the Home Agent was already returning an
error.

	Charlie: I don't know if there's anything to be done. 

	One implementation upon error would set the lifetime to zero.  

	Reverse Tunneling Private addressing - the RFC was not clear that
	the private address support was mandatory, since it was in the 
	appendix.

	Basavaraj:  Samita is working on a draft that clarifies this.

	Should Failed registration replies contain the challenge?  Pat will
	fix the text

	How does the FA track the challenge sent to MNs that solicit for 
	advertisements?

	Final coments:  Issues with agent solicitation.  Dynamic home
address
	allocation -- Who should give out the addresses? AAA or HA?  

Handoff Discussions
-------------------

>>George Tsirtsis(IPv6 fast handoff):

	We have made changes to the design team draft.  We have a new
	type called fast binding update.  The other change is that
	there is a new type for advertisements.

	Michael Thomas:  Is this the fast v6 handoff?  Brought up an issue
	on the seamoby list.  What you are in fact doing is context
transfer.
	You're loosing flexibility on fast mobility.  There may be cases
where
	you don't want the routers know about each other.
	If the problem is solved already, why 

	Someone:  Your objection is to the transfer.  

	Design team guy (DT):  The only purpose of the ICMP is to get the
COA
	of the mobile.

	Michael Thomas (MT): It is moving the state.  What is being positive
	here is a vessel for what seamoby should be doing.  

	Basavaraj:  The packet *could* be used for context transfer.
	But, we're not doing context transfer.

	MT:  But now, we'll have two different messages sent to move a
mobile
	node.

	Eric Nordmark:  Charter issues are not a good use of our time here.

	Next steps - Face to face meeting . . . as soon as next week.

	Discuss ping-pong, bucketing, resolve comments from mailing list, 
	release a new version.

	Someone:  As soon as the MN gets a new layer2, it should be able to
	send packets right away.  Currently to rely on the neighbor
	advertisement adds a round trip time.  

	George:  We are looking into some optimizations.

	Someone: If mobile node has packets to send, then it needs to be
	able to send them.  Even though it can't receive yet. (Until the
	update is finished)

	MT: There are three things going on.  I think it would
	be very useful to decompose them so that you can choose to do any
	of the three, but not be required to do all three.

	George:  It is very tightly coupled.

	Gopal: The messages are not tightly coupled . . . . or maybe they
	are.

>>Karim:
	Low latency handoffs in ipv4
	Compilation of the fast and pro-active handoffs.  

	Current draft is just the combination.

	There are new comments from Monday design team meeting.

	Requirements:  Decrease L3 handoff disruption.  Limit dependencies
on
	L2s.  

	Two methods:  Network Assisted Mobile and Network controlled
(NAMONIC)
			Network Initiated, mobile Terminated (NIMOT)

	Work ongoing trying to get the two methods more integrated.

	Planed additions:
		rewrite intro
		include L2 trigger chart
		Make methods independent of Regional registrations
		move RR application into new section.
		move bicasting to new section
		NAMONIC Mobile Initiated:  new extensions to (Proxy) Router
			solicitation to include L2 ID (eg. AP ID)

	Michael Thomas:  It would be nice if the terminology between the
IPv6
	and IPv4 were the same.  

	Jim: I think the terms should be the same, but don't merge v4 and v6
	hand off documents.

	Gopal: I don't think there is any need for hierarchical stuff in
this
	draft.  

	Design Team(DT):  This is to make IPv4 handoff faster.

	Gopal:  A proxy registration will also make it fast.

	DT:  Take it to list.

	Someone:  Hierarchical MIP helps you with the handoff?  Is that
	what you said?

	DT:  It *could* help reduce the latency.

	Someone:  It doesn't go any faster than basic fast handoff

	Pat: We didn't put hierarchical in the draft to make it faster, we
did
	it to show that it could coexist.

	Someone else:  In bicasting, it is assumed that you know the new
	COA, right?

	Mikael Dagermark:  E-mail archive website doesn't work.

	Phil:  It's being worked on.

	Someone:  Are design teams closed?  

	Phil:  Yes.

	Pat: I don't think the V4 group is closed .. . don't even think it
	exists anymore.

	Phil: take it to the list

>> Youngjune Gwon

	L3 triggering.

	L3 triggering provides the mobile with the best next future agent
	to send a solicitation to.  L3 process may be independent of L2
	information.

	Why use this?

		Access L2 diversity (WLAN, RAN, etc)
		Changes in L1/L2 affect L3 minimally . . faster deployment
		Inter-access technology handoffs
		Useful if L2 triggers not possible.

	Operational Summary
		Network layer mobility prediction
		L3 per packet latency prediction
		access point selection
		 -  next agent selected - 

	Architectural assumptions
		Latency must be measured between MN and BTS
		MN is able to listen to different Base stations
simultaneously
		L3 signaling is essential   .. . L2 signaling is even
better.
		Multi L3 links to BTSs
		Multiple L3 entries possible for same L2 link.

	L3MP - Latency prediction
	     - Access point selection.

	Latency measurement 
		Router advertisement packet
		Simpler packet format using ICMP timestamp (ping)
		IPHeader with agents ipaddress
		authentication (optional)

Discussion at end of this report in section A3

Improving network renumbering in MIPv6
--------------------------------------
TJ Kniveton
	Today's situation

	Draft 13 shows how to renumber

	There were some issues . . . we're going to present our solutions:

	Tunneled router solicititaions are sent from the HA to the MN when
the
	MN is autoconfiguring.

	Problems:  Bootstrap - The MN is autoconfiguring itself.  MN should
not
	use unspecified address - Hard to form security association.

	Problems: Efficiency - Encap. seems to be a way to get around the
TTL
	issue.  Excessive info is sent to mobile node.  Encap not necessary.

	Available Options 
	   Bootstrap Issue
		Relax neighbor discovery TTL rule.
		create a new rule for processing unicast.
	     or
	     	Create new ICMP types for mobile router solicitation and 
			router advertisement.

	Recommendation
		Create a new ICMP type
		Other issues like flag cleanup, redefining and simplifying
		rules for prefix inclusion, and simplified rewording are
		also recommended.

	Michael Thomas (MT): These sort of things (tunneling) security
really
	does matter.  You need to not ignore the security issues.  [ed: TJ
was
	flippant about the auth header being left off of his diagram]

	TJ: agreed.

	Charlie P: Maybe it is advisable to not use AH, but include auth
	data fields.  (from previous sec. problems with AH)

	MT: The situation between the HA and MN is not the same problem of
the
	MN to the Correspondent Node.

	Charlie:  I think we agree that the MN and HA already have a sec.
assoc.
	I was just saying that we won't be using the bit format of AH

	TJ: There is a broader issue with bootstrap.  If a mn boots up on a 
	foreign network, how does it know it's HA?

HMIPv6 
------
Hesham Soliman

	Motivation / Requirements
		Reduce mobile ip signaling load
		improve mobile ip handoff delay
		location privacy
		route optimization for mobile networks
		minimal impacts on mipv6 and or ipv6
		reliability (robust routing)
		scalability

	Changes from last revision

		Introduced load balancing
		additional support for location privacy
		an optimization to allow the MN to encapsulate the
			HA BU into the MAP's BU
		General editorials

	Load balancing
		If across access technologies, a new sub option goes to the
MAP
		and requests that a particular connection go to the other
		net.  Maybe even per-packet load balancing could be useful.

		We put it in, but we believe that it's not a good idea.

Detailed discussion in section A2.

>>Two more scheduled timeslots had to be cancelled as the time allocated
for the WG ran out. The other two slots were:

1. Dynamic configuration of Mobile hosts (Sandy Thuel)
2. QoS Discussion (Hemant Chaskar)

============================================================================

A1: Security in MIPv6 discussion
--------------------------------

	Questions:
		The larger problem is address ownership.  

		Charlie:  Likes minimal requirement :)
			We should meet minimal as soon as possible.
			Other requirements are extremely difficult to
			meet.  Especially when three parties are involved.
			Whatever we come up with we need to be fast and 
			simple.  Any key establishment we set up might
			be vulnerable to man in the middle.  

			Jeff: Agrees with Charlie in general.  But, it's
			up to the WG to pick a proposal.

			We want something that can be implemented by every
			correspondent node, and is easy to implement.  

			Jeff: Minimal requirements have a problem because
			we're saying a man in the middle attack is ok.
Today
			this is the minimal requirement.  In another year,
			it might not be the minimal requirement.

			There are a number of ways of doing it, and they all
			have advantages and disadvantages.  We need to find
			AN answer that meets the requirement, and go with
it.

			Jeff: But, if we pick one, and it turns out to be
			vulnerable, we might not be able to fix millions of 
			devices who's algorithms might be in ROM.

			My *oops* e-mail has an approach that meets the
minimum
			requirements and only uses MD5.

			AH comment:  AH doesn't do what we want to do
because
			we'd have to do it on every packet, only the ones
with
			binding updates on them.  I thought the SPI told you
			how to carry out the authentication.  So, what's the
			problem?  Maybe we just need to slightly change AH
			to pick out the right association and use only 
			authenticate the proper question.

			Jeff:  That is not a discussion for this working
group.
			If you receive a packet with no AH header, how do
you
			know if you can accept it based on IPSEC.  One could
			fix that, but it would not be soon.  (See previous
			comments on "timely")

		Someone: 
			What's required now is a design team.  That design
			team should include implementers, not just abstract
			architecture people.  We need your view on what
			IPSEC does.  How do we not misuse AH again?  This
			is FUBAR and should not have happened.
			Could we do a mock last call on the rest of IPv6,
			we need the spec on the market.  3gpp is waiting on
			it.  

		Phil:   It's already gone through last call.  It's just
waiting
			on security.

		Moskowitz: HIP will allow for man in the middle protection
if
			one of the parties is not anonymous.  So, if the MN
			knows the HA, then it can be avoided.

		Francis: Allowing for man in the middle attack makes the
			minimal requirements too easy.  The problem of PKI
			is difficult problem.  Perhaps we want too strong
			security.  It's easy to avoid the man in the middle
			attack  . . . . hard to understand.

		Jeff:  To guard against man in the middle you only have to
			authenticate strongly one side.  Perhaps you should
			strongly authenticate the correspondent node, and
			put his public key into DNS.  If DNS security is 
			deployed, then we get a security upgrade, and it's
			protects against man in the middle.

		Michael Thomas:  Authorization is not the same as
			Authentication.  Even if we could authenticate, it
			does not say who is allowed to have a particular
			address.

		Jeff:  If we're not careful, we could get into a case of
			diminishing returns.  In practice traffic re-routing
			is not a problem.  Why would you want to send your
			traffic somewhere else.  There is a problem if you
			can say "send that guys' traffic to me"

		Michael:  The schemes that are floating around require a
			reachability test.  What I don't understand about
			PPK draft is, "What are the public keys giving you
			beyond what the reachability gives you?"  What's
			the difference between that and symmetric keys.

		Jeff: 	Correspondents don't have to store large numbers of
			secrets.

		Michael:  So, basically it's a memory vs cpu issue.

		Jeff:  And, the mobile node doesn't have to keep state.

		Someone: I have no expertise in key exchange/generation, but
			I'm curious about the AH problem.

		Someone else: I'm not a fan of triangular routing.  I want
			to make sure no one has called into question the
			security between home agent and mobile node.  We
need
			to get this right.  Don't rush it, even if 3gpp
needs
			it now.  They can live with triangular routes until
			we solve this problem right.

		Phil:   From now on, only questions specific to this point,
not
			ways to solve the problem.

		Someone: The requirements are the same ones that we had for 
			IPv4.  But, barely good enough security was
considered
			no longer secure enough for route optimization.
			So, now suddenly, it's ok again?

		Jeff: I can't comment on the history.  If I had it my way, 
			I'd want something much stronger than this, but I'm
			willing to compromise.

		Someone: Mobileip is out there.  It's been through several
			last calls.  

		Jeff:  We need to move forward.  Why rehash the past.

		Someone:  But, why is the IESG doing this now?  Maybe that's
			our fault, maybe IPSEC's fault.  But, we need to do
it
			right this time.  Not do all the machinications and
			at the last minute get held up again.

		Jeff:  The IESG is VERY busy.  Let's not try to design
process
			to deal with a point solution, because
			tomorrows problem will be different.
			
		Gabriel:  I like the PPK basic idea.  What I think
			would make it even stronger would be to do the
			homework.  HIP has been working for over a
			year.  We need to do a little bit more
			architecture to him (and not solve the point
			problem) so that mobile IP and other protocols
			could leverage it.  If you do the homework on
			PPK, you'll probably end up with something
			very much like hip. 

		Someone:  I think cookies are sufficient.

		Charlie:  There are two possible ways to get done.  one is
to
			put out a ipv6 spec that doesn't require AH any
more,
			but requires some kind of binding key.  Then,
release
			another draft on how to come up with the binding
key.
			That way, IPv6 can go through last call, and the
			security will not hold it up.

		Jeff:  To see if security is secure, you have to do an
analysis.

		Charlie:  But, I wasn't talking about the algorithm, I want
. 

		Jeff:  What I want is for it to be secure.

		Charlie:  But, what you do is put out a draft, and then
decide
			how to make a binding key later.

		Jeff:  I think you have to have a complete solution.

		IPSEC guy from sun:  There were some comments as to whether
			AA was appropriate, or IPSEC was appropriate.  Most
			implementations made tradeoffs for simplicity.
Adding
			complexity there is not something we're interested
in
			doing.  So, not authenticating binding updates is
			not good enough

		Phil:  We will be setting up a design team.

A2:  HMIPv6 Discussion
----------------------

	Michael Thomas:  Using terms like "Mobile Routers" is not a good
idea,
	unless you consider hosts behind them, and mobile routers behind
	mobile routers.

	Hesham Soliman (HS): Leaving that part out doesn't bother me.

	Someone: Increasing robustness creates delay.

	HS: Solution should be as robust as possible. . 

	Someone: In the presence of fast handoffs, this does not provide any
	improvements in delay.

	HS: Agreed.

	Jim: Charlie sent good comments to the list.  I think that the load
	balancing really needs to go.  It is dangerous.  In general it needs
	some editorial work.  There are lots of ideas in here, and probably 
	needs to be cleaned.

	HS:  I think that the comment about load balancing should not be
	used with TCP can be removed.

	Jim:  There are two requirements that I didn't see there:  Signaling
	and per packet overhead must be reduced.  And, arbitrary levels of
	hierarchy must be possible.

	HS:  overhead was to be solved with header compression.  We'll
	take that to the list.

	Jim:  I don't know of any evidence that header compression will work
	on mip packets. . .not that it won't, but it needs to be studied
before
	we rely on it.

	Jim and HS - go offline.

	Someone: If you're making a routing decision on a packet or port,
then
	it's a Layer four switch.  Changing that policy dynamically
	(what you're suggesting) is not routing . . it's embedding
	single points of failure in the network.  

	Someone else:  I agree that any level of hierarchy is bad.   I want
to
	raise a couple of issues about scalability.  I fyou're using only
one
	layer of hierarchy, your signaling the one route you choose.  And if
	you change the route you register with all the corresponding nodes.
	So, this means that in the design you specified you support only one
	box, and you overload other functionalities like bicasting and load 
	balancing.  

	HS: So, the issue is using one box?  I haven't seen any other
proposal
	that uses more than one box.  

	Charlie:  I don't like having two modes of attaching a coa.  the coa
in
	the map, vs the coa in a little source route.  I don't think the mn
	should have an address on a network that he knows nothing about.
So,
	my proposal is that the basic mode be removed, and the extended go
	forward.

	One other note is that the draft talks about too much.  It doesn't
need
	to talk about configuring the routing network, load balancing,
smooth
	handovers, aaa, etc

	HS:  We just mention them, we don't discuss them.

	phil:  There is a lot of feedback about the draft.  We need to take
	this to the list, and decide what really belongs in the draft.

	Samita:  will take her comments off line.

	phil:  Did not get to dynamic configuration, qos, and agenda.

A3 : draft-gwon-mobileip-l3mp-mipv4-00.txt)
-------------------------------------------

	Similar to other handoffs, except it is triggered by L3 predictions.

	Jim: This is not independent of the L2 access technology.  All this
	is doing is sending a beacon.  RFC2002 says that it is ok to beacon.
	The reason we have fast handoff discussions is because this is not 
	fast enough.  This is not L2 independent.  In 802.11 you can not
choose
	access points, you don't have control over it.  This will not work
on
	a wireless lan.

	Alper:  How can you map L3 latency to L2?  

	Youngjune Gwon (YG):  All that we want to do is perform a L3 hand
off
	based on L3 variables, such as latency.  

	Alper:  So, your L3 tells L2 to handoff now?

	YG: That's possible

	Alper: The beacons have to be fast, or this won't work.

	YG: that's right.

	someone:  I think you're describing a basic implementation of MIP.
I
	think if you have a draft, it needs to show how it normally
	doesn't work with MIP.  

	Michael Thomas:  I don't see what you're trying to do here that is
	not already supported by mobile ip.  Can you clarify what
	problem you're trying to solve here that is not already solved.

	Basavaraj: There may be ideas here that would be of interest
	to the design team.

	Someone else:  Are you talking about latency between the mobile and
	the routers.  Have you considered multipath in your latency?

	Phil: Take it outside . . .

	Discussion curtailed as it was felt that this work was not in
	the current scope of the Mobile IP WG.