Subject: [mobile-ip] minutes from Minneapolis

From: Phil Roberts <[email-masked]>
Date: Wed, 3 Apr 2002 19:54:28 -0500

Thanks to George Tsirtsis again for recording the minutes:

IP Routing for Wireless/Mobile Hosts WG (mobileip) 

Tuesday, March 19 at 0900-1130
===============================

CHAIR:	Basavaraj Patil, Phil Roberts
Minute Taker: George Tsirtsis

1. Agenda Bashing, Basavaraj
   Document status
   
Discussion about FMIPv4/v6. There is no progress at the moment. 
There was some interoperability test for FMIPv6

2. Registration Revocation in MobileIP
The speaker solicits interest for the draft. Some private discussion has
taken place but not much in the public domain. Show of hands for support of
this work was requested. 
Someone from 3GPP2 stated that this is one way of doing this but there are
other ways too. A few people showed interest so the work will go ahead

3. Connectathlon Update, Samita
-Mobile Ipv6 draft version 15. 10 participants
No major problems were reported
3 implementations had support for authentication sub-option, no other
security mechanism was tested

Two Questions:
How useful is the "refresh" field in BAck? Should this be dropped?
Charlie: Suggest we make it an option since this is not always needed

-FMIPv6 Handoff
2 implementations
A number of issues will be sent to the mailing list by Alper Y.

-MIPv4
6 implementations
RFC3024 was implementated ut all missed the LPAS feature
No major issues

4. Mobile IPv6 Discussion
Phil R talked about MIPv6 security progress the last few months

4.1 MIPv6 Design Team - Jari
Draft was sent to mailing list a couple of days ago
-Pre16.txt is the actual spec, pre16.pdf describes the changes Draft version
17 will also be needed. Main changes are in section 4.4 and 5.1 There are
now 5 messages needed but only 1.5 RTTs, 2 messages sent via two paths at
the same time

Hesham: is it still worth making BUAck mandatory?
Jari: the issue will be taken into account
Charlie: We need to specify how long does the MN need to wait for the
messages coming back

Francis: Verified/non-verified terminology should be used
Charlie: Mobility Header should be called Next Header Type
Erik: This may confuse because this is a terminal header for MIPv6. There is
need for some text in the spec to clarify

Vijay: Shouldn't the Home Address in BU is a parameter rather than fixed?
Jari: maybe this is a good idea, take it off-line

Jari: Discussion about retransmission strategies is needed Discussion about
the nature of the security association between MN and CN.

Francis: You need R-bit in the BU
Erik & others: this is taken out in earlier spec
Jari: Take it offline

Hesham: To protect the CN from DoS attacks the CN runs in stateless mode.
Isn't the MN vulnerable to the same attacks? The CN could be the bad guy
Jari: Someone needs to remember something and the MN benefiots mostly from
this
Hesham: Yes but it is still a problem
Erik: So what is the concern?
Hesham: The CN can create state in the MN just by sending Binding Requests
Jari: Very little you can do about this
Erik: MNs could have intelligence to only do RO with CNs that make sense to
do so
Hesham: Some text about this would be useful.
James: Have you done a stady on what the impact would be to create statefull
CNs and stateless MNs as opposed to the other way around??
Someone: this is also allowed by the specs

Charlie: Draft 16 is interim.no one should implement this. Draft 17 will be
the real one Jari and Chairs: YES!

Charlie: Are we really considering using IPSEC as the sole MN-CN BU auth
mechanism? This is too heavy!
Hesham: This maybe used instead of HoA test
Jari: Maybe

4.2 Currently Open Issues in MIPv6 Base Spec
Erik N for the Design Team

-Many Editorial Issues
   -Max Binding Lifetimes should be defined (5min?)
   -State Tables for CN, MN
   -Better Terminology for "RR Procedure" COT/COTI/HOT/HOTI
   -Better names for message types

Charlie: Need to make sure we allow static security configuration for
special cases
Thomas: Are you asking for the spec to say that the Bus can be secured by
mechanisms outside this doc?
Charlie: we should say which bytes MUST be protected but the way this is
done should not be restricted. In the IETF we define ONE way of securing the
Bus but this should not be presented as the only one.
Someone: Agrees with Charlie

More Open Issues:
-Bit Method to prevent bidding down attacks

Malinen: wants this method to be in a different RFC. There could be other
methods of expressing the fact that you do not want to do RR. Lets get a few
ways and pick one.
Phil: This is a complex issue, There are arguments that this is needed in
base spec Pekka H: when we do Security engineering as opposed to normal
protocol specification we specify that we MUST NOT do something. This has to
be in base spec. It is not possibly to put in different document something
that prevents something in the Base spec from happening.
Thomas: the Base spec needs to have code here so that all nodes supported
otherwise it can never be used Bob H: Are you suggesting the bit will say do
not do RR but will not say what to do instead. Isn't this an attack itself?
Erik: Now all will do RR but when a new mechanism people will be able to use
it. This is only for your own communication and does not affect others Bob
H:  Concerns about the idea to reserve bits in interface ID of the Ipv6
address space. Addresses are defined as global/local/unicast/mcast etc.This
is a peculiar use of this and in the future we could have other ideas that
need the same.This may not be a good path to take
Malinen: There is need for this but the bit idea may not be the only
one.Unclear at this stage

Raj: Is it not possible to deprecate RR altogether in the future?
Erik: You can not do that because it will have to be done in all nodes, all
Internet
Malinen: the same was done with going from MD5 to HMAC in MIPv4
Erik: Yes but that does not affect CNs!

The IPv6 WG will discuss reserving bits for this in ther Ipv6 WG meeting in
Thursday. We need to make the usage case in MIPv6  

Issue: How and whether to authenticate the BA and BR
Should we add a nonce in BU which will be returned  by BA/BR? Is this
enough?
Vijay: For the BUAck you can use the same key you have for the BU. BR is
different.
Hesham: It is not different because the CN can only send a BR after a BU has
been received

Issue: Whether to authenticate to BM?
The BM can be spoofed by off-path attackers, which would cause some more
work but no ill effects

Issue: Should HAO be used in the Home Registration or not?

Issue: How to secure home registrations, use ESP or AH?
Someone: If you use ESP how are you going to secure the CoA?
Vijay: You need to repeate the CoA in the BU itself, can not rely on the
source address of the packet
Erik: Yes, that is right.

Issue: Is it useful to have an SPI field in the packet
It is not needed for RR but maybe could be added as an option by future
mechanisms
Charlie: We need to allow manual and other mechanisms but the SPI could be
an option

Issues will be sent to the mailing list for further discussion

5. LMM Requirements, Carl draft-ietf-mobileip-lmm-requirements-01.txt
Suggestion to move on the requirements document to last call.
Carl: Jari has one possibly new Security requirement
James: We need one solution on this.
Phil: Jari please post security requirements to the list. Also everyone
check how the MIPv6 discussion affects this.

6. MIP/VPN Issues, Phil
draft-adrangi-mobileip-nat-vpn-problem-stat-req-00.txt
eFarid on VPN traversal for MIP

Phil: Is this a problem the WG wants to solve?
GeorgeT: The Work are needs to consider the larger picture i.e.: HA inside
and outside of the firewall.
Someone: This is definatelly an issue and needs to be resolved. 
Bob H: This is waist of WGs time. By the time this is really a problem you
should be solving it with Ipv6
GeorgeT: This is also a problem for MIPv6
Someone: But then you do not have the NAT issue
Phil: George should propose extended scope for the work the list maybe split
between NAT and Firewall traversal.

7. NAT/NAPT Traversal, Henrik draft-ietf-mobileip-nat-traversal-00.txt
Someone: There is at least one backwards compatibility issue
Henrik: Yes we know about this and we can consider it.
Phil: We will issue last call after the IETF

8. MIPv4/AAA Keys Open issues,  Phil
Phil: some issues seem have to been resolved. Only issue is
re-authentication
Charlie: all changes are in the last draft.
Phil and Charlie agreed that the changes are small enough that no new last
call will be needed.