Subject: [mobile-ip] salt lake city draft meeting minutes

From: Phil Roberts <[email-masked]>
Date: Fri, 4 Jan 2002 14:04:54 -0500

Hi folks,

   here are the draft meeting minutes from Salt Lake City.  Thanks to George
and Raziq for taking notes.  Please let me know of mistakes that need to be
corrected.

Thanks,
Phil

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

IP Routing for Wireless/Mobile Hosts WG (mobileip)

Wednesday, December 12 at 0900-1130
=====================================

CHAIRS:	Patil Basavaraj, Phil Roberts  

AGENDA:

1   Agenda Bashing, 10 Mins, WG Chairs, WG Doc Status update

Document status

- RFC2002bis
Charlie P.:
What to use on RegRep when MN has no HoA? 0.0.0.0 does not look
good....maybe all 1s? it does not really matter

- Aaa-key and gen-key docs to be merged
- v4/v6 fast handoff drafts keep working on it. V6 doc is tied to MIPv6
security discussion
- QoS and MIP interactions will be continued on NSIS WG
- NAT/VPN traversal draft become WG items

=>Announcement about Connectathon 2002 update
MIPv4/v6 will be tested
March 4-7 in San Jose 
Contact: email: [email-masked]

2   MIPv6 Security Discussion, 75 Mins
Discussion lead by Gabriel Montenegro, Jari Arkko and Erik Nordmark
Eric: Gabriel, Jari and Erik have looked at all the drafts and try to come
up with the best solution.  These presentations identify unresolved issues.

- Jari talked about
http://www.ietf.org/internet-drafts/draft-arkko-mipv6ro-secframework-00.txt
Decisions needed:
+ How strong should IFL be
+ Are Binding Security Associations (BSAs) needed?
+ How to implement BSAs
+ How to provide IFB auth?
+ Do we need to apply IFL if IFB is being applied?
+ How to provide protection between HA and MN?
+ How to carry Bus?
+ How to piggyback Bus?
+ Is the HoA a DoS problem?
+ What do about HoA
+ Is the Route Header a problem?
+ What to do about the Route Header
+ Is it worth doing DoS protection?

- BU Security Proposals by Gabriel M.
2 main types of solutions Return Routability (RR) and Cryptographically
Generated Addresses (GSAs)
+ RR
RR without BSA
RR with BSA
RR with BSA #2
   Double path variants possible
Some vulnerabilities:
RRnoBSA: Passive and active attackers
RR_clearKey: Passive and active attackers
RR_DH: active attackers only
Minor differences with MIPv4

+ CGAs
No infrastructure required crypto relation between address and signature
Very strong inherent authorization
More cost:
-	Hashes are cheap but
-	Two heavy repeated operations couple of orders of magnitude more
costly due to DH
-	One-Time done offine?

More expensive than RR but is it an issue?  Should not be a big problem for
terminals
    Someone: There may also be some problem with scaling the Servers with
the PK operations
No hijacking or operations by non addr owner possible.
Other possibilities are:
-	offload CGAs
     o use MN0HA trust
     o Potential additional round trips + previous ones on CGA
-	DH variants
-	CGA with RR
     o This could be good but need to be careful about reflection attacks
using the protocol itself.

-> Performance On 16MHz dragon (palm)
SHA-1: 2.7msec per block
160 bit DH key agreement ~500ms

-> IPR issues?
-	CGAs (Ericsson, Microsoft)?
-	Puzzle?
-	Other?

-> Key Questions
1) Is to ok to be subject to passive attacks?
     o If not RR_noBSA and RrclearKey are not good enough
Erik: This is about passive attacks between CN and MN
2) Is cost difference between RR_DH and CGA significant? 
3) Is the stronger security property of CGA desired?
4) Offloading schemes worth the complexity?

Michael T: Are we moving to something that requires Hard State? In CGA you
can be stateless but you need state anyway because of Home Address Option so
there is no benefit.

Someone? What is the difference between passive and active attack?

Gabriel: in active someone needs to be in the path...i.e.: it is harder

Raj: Passive attacks may be done from anywhere

Christian H: Microsoft send letter to IETF about potential IPR on CGA

Someone: Even with BSA we have no hard state

Erik: Do not think there is much difference between passive and active
attack...attacks most probable close to the MN (e.g.: in wireless LAN) which
is trivial to do either type of attack. More difficult to do active attacks
in the core net.

Someone: on q4. Servers that have many MNs on them will have hard time with
offloading

Gabriel: Offloading is in optimization so possibly useful but may difficult
to do fast

CharlyP. About Q4 should be double but should be invisible to CN

Jari: If MN is Constrained in power then this may not be true...if both
sides have a way to signal this then it will be better

Charlie: we are asking for features that are beyond these offered by current
Internet. We should think about what is it that we actually need further
than what security we have today. There should also be some flexibility
depending on applications so we need to think about what is the minimum
needed.
Gabriel: Level of protection in wireless and Mobile IP is much bigger
because they security exposure is bigger.

Thomas N: Q1 There are a lot of DoS attacks that are passive. The question
is what are the new attack opportunities that Bus bring? And do we want to
secure those. Also CGA may be more stateless but at some point one end needs
to have the verify the Key in which case you will need some state anyway.

Gabriel: But you can only included when you needed in which case it is
stateless

Hesham: Yes we do need more security than today because we do more things
than before (i.e.: Bus)

Christian H: We need strong security. Also RO is an optimization anyway so
we should design it so that protection should be controlled by MN so we do
not loose connectivity. This way we can fall back to triangular routing if
MN-CN can not agree on protection required.

Markus L: IF you consider on axis attacks then there is no difference
between passive and active attacks

Michael T: Fallback is a good thing but  we still have a problem with the
IPSEC tunnel black holes

Erik: So we can not remove the RR_noBSA/Clear Key based on the
passive/active attack arguments.

Michael T: All of them are subject to Man in the middle attack. At least in
DH you are only vulnerable at the start of the communication

Erik: CGA is not vulnerable to Man in the middle

Michael T: Actually you can

Christian H: But in CGA you have to prepare the attack. If you cannot tie IP
address to high level ID then you do not know how you are talking to.

Erik: So in CGA you always know you talk to the right address so Man in the
middle attacks are hard. But is this desirable? TCP is vulnerable to these
attacks today...so maybe it is not needed.

Hesham: some types of active attacks that we do not have today like
hijacking connections. CGA does not allow that.

Discussion about the vulnerability of CGA to man in the middle. Michael T
argues that even CGA can be vulnerable in some case. Others say that it is
much less vulnerable since it does no allow hijacking

Raj: Based on "do not harm" how do we go forward?

Steve D; Do we know intentions of IPR?

Christian D: Microsoft is granting fair and reasonable non discriminatory
rights.  Ericsson seams to have similar policy

Phil:  Q4 is optimization so lets deal with this later. Michael T should
document what the man in the  middle vulnerability of CGA. 

No consensus yet more discussion on the list

-	Home Address Option and Routing Header security Reqs by Erik
Trying to understand interactions between HoA option header and ingress
filtering, ITRACE, IPPT etc. If non of these is used then source address
spoofing could be used for reflection attacks.
Discussion about ITRACE
Discussion about IP in IP tunneling VS Home Address Option security issues.
Discussion about HAOpt idea: CN drops packets with HAOpt unless there is a
matching binding cache entry for sending <HoA, CoA>

Francis: We should instead improve ingress filtering...describes high level
idea

Erik: You should right this up because I do not think it is possible

Phil: Please right up the proposal

Michael T: Important thing is that  if we want ingress filtering we can
either put it in ARs or in CNs...more need work. But what brings better fate
sharing? The AR will do better in this.

Hesham: What happens with BNACKS on reboots?

Erik: That is why we need ICMP error message

Hesham: How do you rate limit?

Erik: Basic ICMP rate limiting can be used

Hesham: I think this is a good idea to go with.

Routing Header Discussion
This is about the MIPv6 use of the routing header

Steve D: Source Routing is equivalent to encapsulation. RH leaves trace of
the path which is better than the encapsulation and box that uses them
should adhere to back trace requirements for general routers. In the special
case of MIPv6 the packets is only forwarded in the box...so these could be
excluded for the router rules

Charlie: Home Address has to be after the CoA and that is the only thing
needed for the MIPv6 application of RH...other apps may have more complex
requirements

3   RFC3012bis: Issues identified and Changes made      10 Mins Charles
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc3012bis-00.txt
Need to specify which bytes to be included in the authentication data
A number of issues fixed.

This will come out soon and will go to last call.

4. Handoffs: Low Latency(v4) and Fast HO (v6)           30 Mins

   a. Discussion of issues based on implementation experience
      James Kempf
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lowlatency-handoffs-
v4-03.txt
http://geocities.com/kempf42/llanalysis.pdf

Asked who else implemented this...No hands were raised!
Problems with Prereg method
Proposed to move Prereg to separate draft keep postreg in standards track
A couple of people actually about to do the implementations so comparisons
are premature.
Hesham challenged whether what was implemented was actually what is
described in the draft.
Karim pointed out that this analysis is based on a very particular network
configuration and results may be different with other configurations.

-------------WG run out of time-----------
   b. Fast handoff - Updates/Changes/Issues raised on list
      Gopal Dommety
http://people.nokia.net/~patil/Internet_Drafts/draft-ietf-mobileip-fast-mipv
6-04.txt   

5. Localized Mobility Management Requirements           10 Mins
   Carl Williams
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lmm-requirements-00.
txt

6. MIPv6 at ETSI Bakeoff Report     10 Mins             Sebastien Barbin