Subject: [mobile-ip] MOBILEIP WG Minutes (56th IETF, San Francisco)

From: gabriel montenegro <[email-masked]>
Date: Wed, 09 Apr 2003 14:17:52 +0200

Folks,

These are the preliminary minutes. Please send any corrections.
I'm planning on submitting the final version on Friday to the
minutes repository.

tnx,

-gabriel

--------------------------------------------------------------
Minutes for IP Routing for Wireless/Mobile Hosts WG (mobileip)

Monday, March 17 at 1300-1500
==============================

CHAIRS: Basavaraj Patil <[email-masked]>
	Phil Roberts <[email-masked]>
	Gabriel Montenegro <[email-masked]>

Minutes by Nick Moore ([email-masked]) and Hesham Soliman
([email-masked]) with additional notes and edits by
Gabriel.

Abbreviations used:

BA = Bernard Aboba
BP = Basavaraj Patil
CP = Charlie Perkins
Erik = Erik Nordmark
HS = Hesham Soliman
JA = Jari Arkko
JK = James Kempf
MT = Michael Thomas
TJ = TJ Kniveton
TN = Thomas Narten

--------------------------------------------------------------
1. Agenda and WG Document Status			10 Mins
    (Chairs)

MIPv6 - last call completed IESG review (discussions ongoing)
MN - HAsec: going to IESG
AAA NAI: completed IETF LC
Reg Rev: completed IETF LC

WG LC:
RFC 3012bis

AAA keys for MIPv4

regional registrations : dormant

Low latency: To go for Exp, no further progress since Atlanta

LMM req: ready for WG LC

Looking for security advice for VPN DT output (problem and
solution draft)

- Suggestions for draft-mccann.mobileip-80211fh-01
(informational?)

- MIPv6 RO background (ionformational?)

- New draft in dhc WG for MIPv4 (take a look)

MIB status -- in the revision to 3044, would the associated
MIB go to draft standard?
TN: no, it advances like any other, going forward as PS.

CP: regional regs is not dormant, there were good comments
from alan o'neill and these were incorporated.
So there has been some progress.

Gabriel: If all the updates were made, we will look into it.

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

2. Mobile IPv6 - IETF LC issues update			30 Mins
    I-Ds:
     o draft-ietf-mobileip-ipv6-21.txt		[15]
     o draft-ietf-mobileip-mipv6-ha-ipsec-03.txt [15]
     (Jari Arkko, Charles Perkins)

Jari on remaining issues.

273 - can a HA be CN at the same time?
Suggestion: ignore a new BU with a different H value
Hesham: This seems like a bug in the MN, maybe an
error message should be sent
CP: I would like to suggest the same.

MT: Should CN->HA actually be illegal or is there a real
situation where this could occur.
JA: Could always delete the old entry before sending new binding.
JA: It's clear that this is an error condition.

277 - what should CN do if H=1?

Proposal: Clarify that RR be used if and only if H=0,
	and Silent discard if RR not used as expected.

No comments. Suggestion seems acceptable

279 - NS src addr from HA to figure out the MN's addr
Proposal 1: start answering NSes after sending the BU
Jari: I prefer proposal 1
??: agree with proposal 1
TJ: I also agree

Issue 281 IESG Technical comments:
Technical: different issues, no problem here.
Issue 281 IESG Security comments:
IKE should be a SHOULD; some work required.

TN: needs to be a discussion, security people need to
describe _why_ it should be a SHOULD.

MT: Should not be mandatory on IKE, but on some flavor of key mgmt (there's
others besides IKE like kink). Not necessary to single out IKE.

BA: IKE will only work with IKEv1 cuz only aggressive mode
could be used (main mode), and then the handling of fragmented
packets won't work, ikev2 won't fix this, you end up with
1/8 of a key mgmt

CP: sequence number already does replay protection for several years
(potentially) using preconfigured keys.

278 - movement detection

HS: proposal #1 (ignore the issue) is reasonable and simplest,
	No point in complicating these algorithms now.
	A MN can change CoA based on new prefix or ll address change.
JK: agree

Ed Remmel: R-bit should be a MUST not just for HA's but for all routers

Charlie: The solution is different depending on the link type. No one
size fits all.	A mandated solution could hurt performance on some media
It would be a lot better to leave it as is.

TJ: I agree with everything said so far. Now is not
the time and place to fix this.

Erik: If people implement this from the spec and doesnt
work then it would be useful to mention the problem
in the spec to reduce the probability of errors in stacks.

TJ: Are there common cases where routers configure the
same ll address on different interfaces?

Erik: If there is one then that's enough.

Vijay: Some implementations use Eager switching and
some don't. There are many different ways of doing this.
There is no need to fix this in the spec. Some warnings
are enough. Perhaps the new MIP WG charter should address
this.

BP: This needs in a different doc. From this
discussion I would say leave it as is and document the
problem.

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

3. Connectathon Update on Mobile IP protocols           10 Mins
    (Samita C.)

All implementations supported rev 20.
2 implementations supported IPsec between
MN and HA based on WG draft.

A discussion for MIPv6 Internet testing. A mailing list
will be setup. Presenatation at www.connectathon.org.

no major issues, just simple clarifications
currently resolved

TJ: there were also 3 implementations on prefix
discovery on home link. First time this was interop
tested and it was successful.

---------------------------------------------------------------
4. Registration Revocation in MIPv4 - LC issues update  15 Mins
    I-D:
     o draft-ietf-mobileip-reg-revok-05.txt
     (Steve Glass)

* CLARIFICATION:  That's 1 revocation PER BINDING PER SECOND.

No questions asked.

---------------------------------------------------------------
5. Mobile IPv4 Traversal of VPN Gateways update         15 Mins
    I-Ds:
     o draft-ietf-mobileip-vpn-problem-statement-req-01.txt
     o draft-ietf-mobileip-vpn-problem-solution-00.txt
     (Gopal Dommety, Sami Vaarala)

Gopal on vpn design team

Problem statement essentially done

MT - do any of your solution allow an IPsec tunnel to
replace the MIP ip-in-ip tunnel?

Gopal - we don't do this cuz you'd need the HA in your DMZ

MT - so? in that particular situation it would be beneficial

Gopal - it's implicitly allowed, yes.

? - how does this mesh with nat traversal?

Henrik: If you wrap the IPsec tunnel in the MIP tunnel
then it will work through NAT. They are two different things
that can work together or by themselves.

CP: It's always been possible to put IPsec with
IP in IP tunnelling.

Gopal: We assume no protocol changes

Charlie: Why can't the HA put IPsec over the tunnel?
It was never prohibited in RFC 2003. You can already
do that without protocol changes

Gopal: MIP is terminated at the VPN GW

Charlie: But you could also terminate it at the HA

Henrik: What Charlie suggests is resonable if you have
a VPN GW with a HA together in one box.

Charlie: Ok, so no protocol changes are needed.

? - how much is applicable to ipv6?

Gopal and BP - not currently targetted, this is ipv4 only
work

---------------------------------------------------------------
6. Fast Handovers for Mobile IPv6 - Issues              10 Mins
     I-D:
      o draft-ietf-mobileip-fast-mipv6-06.txt
      (Rajeev Koodli)

tunnel establishment hi/hack only after processing fbu
	less state to keep

revised fna

issue: how to secure FBU
	depends on trust MN-PAR

MT: What is the difference between MN-HA security association and MN-PAR
	relationship anyway? Why the different mechanisms?

JK: Possible answer for this by ending tunnel in NAR, needs
	further discussion.

HS: Why we can't use IKE: address ownership problem. CGA's would work, otherwise
	it's hard

Alper: Roaming node may need many trust relationships maybe
	use SEND mechanisms?

Rajeev: must be a solution in the FMIP draft.

CP: Two cases: how do you set up associations, how do you transfer
	`associations?

JK, HS: Draft can't advance until security at least referenced.

Erik: Maybe as _experimental_ without security.  Maybe it's possible
	to build a shared secret to authenticate MN to PAR communications.
	via PBK/anonymousDH.

---------------------------------------------------------------
7. Optimistic DAD and Non-Predictive Handovers          15 Mins
    I-D:
     o draft-moore-ipv6-optimistic-dad-02.txt
     (Nick 'Sharkey' Moore)

Erik: Will the router override send packets to the
optimistic node if an entry already existed
for anothe node?

Nick: Based on experiments I found that it will
continue to send packets to the old node, not the
optimistic node.

Thomas: There is a problem with a packet sent
to foo and received in another node then that
node might RST the TCP connection
Nick: It won't happen, the node does not override
an exisiting entry.

James: How do you get Fast RA if you don't have
L2 triggers?

Nick: Fast RA just means answering the RS without
delay.

BA - good papers on arbaugh on delays caused by
scanning, but l2 on802.11 now seen as little as 40ms

Hesham: So is it fair to say that the difference
between predictive and non-predictive handovers is
the L2 handovers?

Nick: Yes.

Charlie: Did you use 400ms with piggybacking mode?

Nick:..... missed it

Charlie: Is there something that needs to be specified
in the piggybacking draft.

Nick: If you don't have outoging traffic then piggybacking
can be harmful.

Erik: So do you assume that the delay to the MAP is
zero? I.e. the MAP is close to the MN?

Nick: Yes we assume that the MAP is pretty close
to the MN, which is true in many cases. Maybe
not all.

Rajeev: So you still have some packets going to the old
AR till the BU arrives at the MAP?

Nick: Yes that's right.

---------------------------------------------------------------
8. Extension to Sockets API for Mobile IPv6             10 Mins
    I-Ds:

Samita on draft-chakrabarti-mobileip-mipext-advapi-00.txt
--------------------------------------------------------
No comments

Alper on draft-yokote-mobileip-api-01.txt
-----------------------------------------

There is an IPR statement on this draft but it will
be removed in the next revision.

No comments

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 14 Apr 2003 10:41:33 -0700

> Ed Remmel: R-bit should be a MUST not just for HA's but for all routers

Just FYI, that's not what I said at IETF56. What I said is that the 'R' bit
information, when it is included in the RA, MUST be consistent with
information in subsequent RAs sent by the same router, i.e. if the router
includes a 'R' bit Prefix Information Option in a RA advertising its global
address, then as long as that address is still valid it must include that
same option in all RAs that it broadcasts. This is so that this information
can be used by the MN for move detection (in conjunction with the link-local
scope source address of the RA). If the information is not consistent in RAs
that the MN receives from the same router, then it is difficult for the MN
to use that information for move detection. Also, it is RECOMMENDED that
other non-home agent IPv6 routers include the R-bit in their RAs. This is
what I suggested in the online issue report.

This issue has to do with the fact that a link-local scope source address is
ambiguous when considered in a larger scope than link-local scope. To
resolve the ambiguity, the MN could also use the 'R' bit information, when
present in the RA, if and only if that information is consistent between RAs
broadcast by the same router. Then, you could add the following MN
requirement to the spec:

"If the Router Advertisement sent by the current default router contains the
modified Prefix Information Option with the (R) bit set indicating that it
contains the address of the router and with the (L) on-link flag set
indicating that it can be used for on-link determination, then the mobile
node SHOULD check each Router Advertisement received from that router (both
unsolicited as well as solicited) to verify that it contains the same router
address, and if it does not, then the mobile node SHOULD treat this as an
indication that L3 movement has occurred."

Thanks.
- Ed

---

From: Jari Arkko <[email-masked]>
Date: Tue, 22 Apr 2003 11:05:11 +0300

> indication that L3 movement has occurred."

This would work for me, but in order to solve #278 we still need two
additional pieces of text, I think:

   1) The home agent requirement to keep a PI with R bit consistent
      for every RA, if R bit is used.
   2) Explain the potential problem with link-local addresses,
      if the rule above is not used, for instance due to an old
      router that does not support R bit.

Jari

---

From: "Ed Remmell" <[email-masked]>
Date: Tue, 22 Apr 2003 08:17:55 -0700

Jari -

>       router that does not support R bit.

Yes, please make all of these changes. Then, IMO finally we will have
successfully addressed the following open issue identified in
draft-nordmark-mobileip-mipv6-hindsight-00.txt:

"  There is also one idea that could be added to Mobile IPv6 at a later
   stage, which is to make the movement detection more explicit.  The
   idea is to configure the routers on each link to advertise a single
   global IPv6 address as the "identity" of the link in each Router
   Advertisement.  This can be done by defining a new Neighbor Discovery
   option.  Thus a Mobile Node when it receives a Router Advertisement
   can immediately tell whether it has moved - the global identity will
   be different for each link."

In this case, "identity of the link" will normally be identity of a single
router (excepting the case when a global scope anycast address is used to
identify a set of routers on the same link, which is one possible way to
implement this), but then in our MN implementation we treat a single router
as a virtual link anyways so same intent.

Thanks for listening ;)

Thanks.
- Ed

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Tuesday, April 22, 2003 1:05 AM
> To: Ed Remmell
> Cc: gabriel montenegro; [email-masked]; Phil Roberts;
> Basavaraj Patil (NTC/Dallas); Jari Arkko; [email-masked]
> Subject: Re: [mobile-ip] MOBILEIP WG Minutes (56th IETF, San Francisco)
>
>
> Ed Remmell wrote:
>

---

From: Jari Arkko <[email-masked]>
Date: Sun, 27 Apr 2003 14:28:12 +0300

And then later as a response to me:

> Yes, please make all of these changes.

So, here's the proposed solution to issue #278:

1. Insert the following text to Section 11.5.1 (Movement Detection):

    "Note that it is possible, even if improbable, that two routers
     happen to be using the same link-local addresses. Therefore,
     tracking the source address of the Router Advertisements may
     not always be sufficient. However, if the Router Advertisement
     sent by the current default router contains a modified Prefix
     Information option with the Router Address (R) bit set, and
     with the On-Link (L) flag set to indicate an on-link prefix,
     then the mobile node SHOULD check all subsequent Router
     Advertisements received from the same link-local address. In
     this check, some of the Prefix Information options received in
     the new Advertisement should indicate the same global router
     address which was indicated earlier. If they do not contain
     the same address, then the mobile node SHOULD treat this as an
     indication that a movement has occurred."

2. Insert the following text to the end of Section 7.2 (Modified PI):

    "In addition, the following requirement can assist mobile nodes
     in movement detection. Barring changes in the prefixes for the
     link, routers that send multiple Router Advertisements with
     the Router Address~(R) bit set in some of the included Prefix
     Information options SHOULD provide at least one option and
     router address which stays the same in all of the
     Advertisements."

--Jari

---

From: "JinHyeock Choi" <[email-masked]>
Date: Mon, 28 Apr 2003 16:14:14 +0900

Hi Jari 

I am afraid there is some problem on the proposed solution to issue #278. 
Kindly find in-line comments. 

>      Advertisements received from the same link-local address. In

I can't understand why MN checks only the RAs from the same link-local 
address. If so, MN can detect movement only when old AR and new AR 
have same link-local address.  

If MN checks only RAs from the same link-local address, it may not detect 
movement even if RA from new AR arrives. 

>      indication that a movement has occurred."

Even though MN checks all incoming RAs, it may result in problem. 

Here is an example: 
R1 and R2 are routers on the link. Each advertise the P1/48 prefix to the 
other routers. Host MN is on the link. Assume R1 is the default router of 
MN and it sends RAs with a modified Prefix Information option with (R) 
bit and (L) bit set. So R1 keep advertising its global address.  

If MN treat the lack of global address of R1 as movement indication, when 
a RA from R2 arrives, it may mistake this incident as L3 movement. 

For Movement Detection, MN should check 
1) The reachability of current AR
2) The validity of the prefix of current (primary) CoA

Though the proposed solution may serve as some kind of hint, I am afraid 
that it helps to confirm neither AR reachability nor CoA validity. 

JinHyeock

---

From: Jari Arkko <[email-masked]>
Date: Mon, 28 Apr 2003 12:45:20 +0300

> movement even if RA from new AR arrives. 

Yes.

But the intention for this new paragraph was to say what to do in the
special case of having the same link-local addresses. I.e. its a new
condition, not a replacement to all the conditions regarding MD.

> that it helps to confirm neither AR reachability nor CoA validity. 

Right, but it wasn't intended to. It was intended to work as an
additional condition for check 1 above. Note that it says "...
check all subseqent RAs... from the same link-local address".
So in your example above, an RA from the R2 would not have
the same link-local address, and its receipt would not be
taken as an indication of movement.

I have reformulated the last sentence of the new paragraph to
make this more clear:

   Note that it is possible, even if improbable, that two routers happen
   to be using the same link-local addresses. Therefore, tracking the
   source address of the Router Advertisements may not always be
   sufficient. However, if the Router Advertisement sent by the current
   default router contains a modified Prefix Information option with the
   Router Address (R) bit set, and with the On-Link (L) flag set to
   indicate an on-link prefix, then the mobile node SHOULD check all
   subsequent Router Advertisements received from the same link-local
   address. In this check, some of the Prefix Information options
   received in the new Advertisement should indicate the same global
   router address which was indicated earlier. If they do not contain the
   same address even if the Advertisement was sent from the same
   link-local address, then the mobile node SHOULD treat this as an
   indication that a movement may have occurred.

Does this work for you?

--Jari

---

From: "JinHyeock Choi" <[email-masked]>
Date: Mon, 28 Apr 2003 19:23:03 +0900

Hi Jari

Thanks for your elaboration. 

> condition, not a replacement to all the conditions regarding MD.

I see. So this deals with only the case of same link local addresses. Let me 
make it clear. So when a RA with different link-local address arrives, MN 
has no information on whether it has moved or not. Right? 
 
> taken as an indication of movement.

Agree.
 
>    indication that a movement may have occurred.

Yes, it works for me. I understand that the above is to give MN hint of 
movement for the special case of same link local addresses. 

Thanks for clarification. 

JinHyeock

---

From: Jari Arkko <[email-masked]>
Date: Mon, 28 Apr 2003 13:37:07 +0300

> has no information on whether it has moved or not. Right? 

Right.

> Thanks for clarification. 

Thanks for pointing out the need for clarification ;-)

--Jari

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 27 Apr 2003 04:53:48 +0200 (CEST)

> >       for every RA, if R bit is used.

s/home agent/router/
since we want all routers that use the R bit to use it consistently.

> [snip]

Ed,
You wouldn't want to use the same "R" address from multiple routers
since that isn't the semantics of the defined R-bit.
The R-bit might be useful outside of MIPv6 for debugging by providing 
a mapping from the link-local source address of the RAs
to a global address of the router.

So it is only in the case when there is a single router per link
that the R-bit is equivalent to what I proposed in the hindsight draft.
Providing something in the multi-router case that is identical when
on the same link but guaranteed (through config of the routers)
to be different than different links could also be accomplished
by requiring that routers always advertise one common prefix (across
all routers on the link) in every router advertisement they send.

  Erik

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 28 Apr 2003 09:47:35 -0700

Jari -

I'm OK with these changes, IMO they do more good than harm.

Thanks.
- Ed

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jari Arkko
> Sent: Monday, April 28, 2003 2:45 AM
> To: JinHyeock Choi
> Cc: [email-masked]