(slides: http://www.mip4.org/ietf61/mip4-agenda.ppt )

Minute taker: Eva Gustafsson

Charlie's presentation regarding 3344bis issues has been moved up, as he has a plane to catch. No other comments on the agenda.

draft-ietf-mip4-rfc3012bis-02.txt

Issue:

3012bis, issue raised with HMAC_CHAP_SPI, proposed solution to delete HMAC_CHAP_SPI from text, i.e. no longer supported.

Comments:

None.

( slides: http://www.mip4.org/ietf61/rfc3344bis.ppt )

Issue:

Issue 45 remains unsolved - what to do if deregistration message fails due to broken foreign-home authentication extension. New revision specifies that FA MUST NOT apply foreign-home authentication extension to MN's deregistration request.

Comments:

Kent Leung:

Thought we had different agreement on mailing list.

Pete McCann:

Agreed that if FA-HA authentication failed, extension must be discarded. (?)

Hesham Soliman:

If anything added on top, needs to be authenticated to avoid man-in-the-middle attack.

Pete:

If extension is there, it needs to be respected.

Discussion...

Question by someone on different issue...

Pete:

Need to take this discussion to the list again.

Henrik Levkowetz & Pete:

Ok to only do this when care-of address was that of another FA, not the FA transmitting this to you? Check lifetime zero, other care-of address, FA would leave on authentication extension?

Kent:

Need to think this over...

Pete:

Exception on FA not to put this on, on HA not to discard.

Q:

Simultaneous bindings?

Charlie Perkins:

Don't see connection with simultaneous bindings.

Resolution:

Action item: Charlie will write this down and send to list

draft-ietf-mobileip-vpn-problem-solution-03.txt

We still need a co-editor to help Sami Vaarala with this. Those interested, please approach chairs after meeting.

Issue:

Last call ended Friday, Nov 5th . One comment received: what does MN do if receives unauthenticated FA extension?

Comments:

Henrik:

Since this message only goes on link local between FA and MN, should not be too troublesome to leave as is. TTL check in this message? Think so.

Kent:

Resolution of wording done in WG? Yes. Should get FA error on MN. Case of MN-FA link being compromised minimal. Need text about MN-HA connection.

Pete:

Need text describing that FA does if it sees this from FA. Should deregister. Be careful; not authenticated.

Kent:

Either go "MAY", or do the ping test first.

Charlie:

Make sure HA does not deliver erroneous message, right?

Pete:

No guarantee that message actually came from HA.

Charlie:

If you get FA error, calls for suspicion, wait a little longer for successful registration reply, otherwise do something about it.

Henrik:

Thinks this is overengineering it. Why dance around this particular one? Just take it for what it is and act on it. Assume link between MN and FA is safe.

Issue:

Old problem. Do we want to take this up in the WG?

Earlier statement that there is considerable work to get acceptable security.

Would like to see some real-world deployment. Which are the customers, what is the security model, assumptions?

Comments:

Hesham:

You got the right question. Also, first question should be "what do you mean by route optimization?". If it's the same as for MIP6, if we apply same security requirements, will be a challenge. Old draft, signaling between FAs would be useful, more useful than full-fledged route optimization.

Pete:

Would like to keep signaling orthogonal to existing signaling.

Vijay:

Think we should do this, not to have all traffic go through HA. Nokia would like this.

Pete:

What link layers? Carrier?

Vijay:

For all environments...

Pete:

We need to pin down what environments need this.

Alexandru Petrescu:

Certain type of route optimization is useful. Is there common idea what this leads to and what solutions we want to work on?

Pete:

Old draft (Perkins, Johnson), also MIP6 type of solution.

Hesham:

We run and deploy MIP4, see no need for route optimization. Whatever we see for MIP6 will be deployed. To enable service, not needed. For efficient mobility, FA-FA signaling needed.

James Kempf:

We don't deploy MIP (4 or 6). Agree with Hesham; we don't need route optimization now.

Hesham:

Low-latency handoffs helpful. Experience says most efficient solution would be low-latency stuff plus hierarchical stuff. We effectively get route optimization with this.

Kent:

Get real customers to come forward so that we can nail down requirements for this.

Pete:

Please post studies etc. on mailing list. Also, doing this in our WG requires discussion with ADs to put it on charter.

Pete:

We need some more support for foreign agent error to move forward.

Resolution:

Humming inconclusive.

Issue:

MIP4/MIP6 combinations. New mailing list created: miptrans@ops.ietf.org < mailto:miptrans@ops.ietf.org >.

draft-larsson-v6ops-mip-scenarios-00.txt ... describing scenarios evolved. Will be submitted as individual submission, as there is currently no WG where it belongs. If you have interest in this area, read draft and comment.

To do MIP4 work in this space, we need clear statement of scenario and environment where you need your solution to be applied, clear statement of which combinations (from draft-larsson...) will be addressed, and definition of problem (why does this need to be done?).

We need to know why we are doing it and how it will apply.

Comments:

Alexandru:

First time I see draft-larsson...

Henrik:

Submitted recently, mentioned it because we want people to look at it and comment.

Alexandru:

Example: MIP6 MN transmitting to IPv4 network?

Henrik:

Yes, this scenario is one of many mentioned in this draft. Would belong in MIP6 WG or possibly in new transition WG.

Issue:

FMIPv4 motivation and design ideas, implementation benchmarks. Available for anyone to work on - will not push this.

Comments:

Pete:

Could you post something about similarities with low-latency on the draft? We need discussion with ADs if we want this back on the charter.

Charlie:

Only two factors: performance and simplicity.

Kent:

Curious on the numbers. Is there a further breakdown on those numbers...?

Charlie:

Numbers due to advertising model.

Hesham:

This is basically fast handoff for MIP6, low-latency. Hard to find difference enough for so significant difference in performance.

Charlie:

We wanted answers as fast as possible.

Henrik:

Very interesting. First two values I recognize from client I used to work on. Would like to see as experimental.

James:

Agree with Henrik. We have a paper where we did extensive comparison. We also did something similar to this; worked very well on WLAN.

Henrik:

Can you send pointer to paper to the list.

James:

Will do as soon as it is published.

Hesham:

Would be really good to see just email on difference between this and low-latency.