[Mipshop] MIPSHOP Session I Minutes

Hello,

here are the draft minutes for Session I. please send
me any errors/revisions. Session II minutes will follow.

Session I
---------

Tuesday, November 7, 1300-1500

1. Agenda review, Blue sheets and volunteers for 
   notes and Jabber                                       5 Mins

2. WG status and I-Ds update                             15 Mins
   draft-ietf-mipshop-cga-cba-00.txt
   draft-ietf-mipshop-fmipv6-rfc4068bis-00.txt
   draft-kempf-mipshop-handover-key-00.txt
   draft-vidya-mipshop-handover-keys-aaa-03.txt
   draft-ietf-mipshop-fh80216e-00.txt
   draft-ietf-mipshop-3gfh-00.txt
   draft-soliman-mipshop-4140bis-00.txt
   draft-haddad-mipshop-hmipv6-security-06

Vidya : how can we have a last call on FMIPv6 before we know what 
the security solution is?

Vijay : draft-kempf-mipshop-handover-key-00 -- waiting for mob dir review

Alper Yegin: Have you received the mobility directorate review of
draft-kempf-mipshop-handover-key

James Kempf: I don't think it needs any more review. It is ready for WG
adoption and last call.

Alper: There are a couple of solutions for the same problem, shouldn't
we review the alternatives?

Vijay: If the alternatives provide a significant improvement, yes.

Alper: Why aren't the others considered as equal options?

Vijay: The WG has spent a lot of time working on this. It is up to 
the authors of the alternate solutions to convince the WG.

James: we have been working on this document for 3 years. We should 
go forward with what we have, and once these are finished, we can look 
at the others.

Vidya: Vidya - If we continue process and exhaust the solution space 
before we pick something, it's not possible. The SEND-based solution 
has been around a long time, and AAA 1 1/2 to 2 years. New proposals
shouldn't be related to existing documents

Alper: Shouldn't we evaluate all the proposed solutions now?

Jari Arkko: Let's look at the presentations today and see how the
alternatives are and make the decisions then.

Vidya: The documents have been through WG last call on adoption. All the
concerns have been fixed.

Vijay: It would be good to see if there are any issues and if the
alternative solutions address them better.

Vijay: May-June timeframe on HMIPv6 solution.

Vijay: 3g CDMA document is being brought closer to 3GPP2 specs

Vijay: 802.16e doc is postponed for now to wait for 16ng to make more 
progress

Stefano: MIH Solutions cannot be processed before adopting a problem
statement

3. Applying Cryptographically Generated Addresses 
   and Credit-Based Authorization to Mobile IPv6
   Christian Vogt
   draft-ietf-mipshop-cga-cba-01.txt                     10 Mins

Wassim: Problem with minimum RSA key length of 384.. It might be 
possible to use integer factoring to break the private key at 384 bits.
Three options for solving this.

Hesham : Do you have a preference? I think the third one makes sense.

Wassim: The 1st one, hard coded RSA key length and the 3rd one, encoding
the key lngeth into CGA would make sense.

Hesham : What if the CN doesn't agree with minimum and rejects it? 
I'm fine with 1st and3rd

Zhen: 704 should be used as a minimum key length, application dependent
Madison: There is research on thuis

Jari A. : Option 3 would be the right way forward. Perhaps we could 
combine with option 1. But I don't know if that's really needed. These 
are keys only used for address ownership, not banking.

4. Integrating IBC with CGA in Mobile IPv6
   Zhen Cao
   draft-cao-mipshop-ibc-cga-00.txt                      15 Mins

Hesham: Could you explain the autoconfig attack?

Arkko: Attacker generates its own keypair and address. What is the
attack?

Cao: If the CGA is used for other purposes than address ownership, then
this is a problem.

Vidya: CGA is not meant to be used for authentication.
Cao: IBC will allow to extend the use of CGAs for authentication.

Vidya: Why is there a need to add authentication to CGA?
Cao: Without authentication the end user cannot be authenticated as
being trusted.

Vidya: There are other alternatives for this.
Cao: This allows to extend...

Vidya: Entity authentication vs. message authentication. Entity
authentication cannot be achieved without infrastructure.

?: Are the CGAs to be enhanced to be used to authenticate the user
using the computer?
Cao: Yes.

Vidya: How is this diffreent from certificates?
?: You do have a TTP?
Cao: yes.

?: What is the benefit over putting CGA keys to DNSSec?

Hesham: What types of applications are you planning this for?

Hesham: Is this the right WG for this work?

Cao: IBC-identity can be used in place of public key for CGA signature
with the help of a KDC.

?: Could be used for FMIPv6 authentication.

J. Kempf: We have done lots of work on this area. Two fundmamental
problems: 1. You cannot use this in an open world. Similar problems as
with PKI.

2. Algorithms are not performing well, 1-2 orders of magnitude worse
than RSA.  Does not think that it is a general solution, although there
are some special cases in which it could be used.

Cao: Trust problem

James Kempf: Address is probably not the right place to do this.

James Kempf: Is tate-pairing needed?

Cao: Depends on the ECC signature used?

James Kempf: ECC also requires this generally, the exceptions have other
problems. Ok for email, but not for IPsec.

Cao: Tate-pairing is not used in the proposal.

Stefano: Move the discussion to the mailing list.

5. Mobile IPv6 Fast Handovers for 3G CDMA Networks
   Hidetoshi Yokota
   draft-ietf-mipshop-3gfh-01.txt                        20 Mins

Intention to apply draft to network controlled handoffs in 3gpp2.

Hesham:: (Immediate Fast handover slide 1) This is not fast handover?

Author: No.

Hesham: There is not one message from 4068.

Author: still presenting the background

Vijay: We are not going to standardize something that has already been
done in 3Gpp2. You are going to show how 4068 can be extended to work
with this?

Author: yes.

?: Clarification, why does MN sends a BU in addition to proxy BU sent by
NAR?

Author: Proxy BU is temporary solution.

?: Isn't this redundant.

Author: Both Simple IP and Mobile IP are supported.

Vidya: Isn't this background?

Author: yes.

Hesham: Simple IP means there is no IP mobility?

Author: 3gpp2 looks at both Simple IP and MIP.

Hesham: Do you need an extension to Handover Initiate in FMIPv6?

Author: Yes.

Vijay: Multiple options: we have a document on this, it can be
informational, or we can design a solution for 3gpp2

Vidya: Get list of requirements from 3gpp2. And make sure that FMIPv6
meets them if they are reasonable otherwise say so. Write a document,

Hesham: Goal for FMIP was to be adopted. If you find that there's
something missing, please let us know. Can you write a informational
document on how you have used it in 3gpp2.

Author: How much should I tweak the protocol?

Hesham: If not too much, please give input for FMIP before it goes to
last call.

Vidya: The work is very useful, gives feedback. We need to get the
requirements, so that we can get community feedback and see what
extensions need to be done, which could benefit also other users than
3GPP2. If you describe how you have updated the protocol, we cannot
easily derive the requirements from that.

6. Authenticating FMIPv6 Handovers
   Suresh Krishnan
   draft-haddad-mipshop-fmipv6-auth-02                    5 Mins

- Use one way hash chain with 128 bit hash values
- Use SEND only in the beginning to anchor hash chain
- 64 bits of OWHC are used for nCoAs.

James Kempf: Is there any problem with using SEND with every AR?

Suresh: It's computationally expensive.

Kempf: Don't you need to do SEND for Neighbour dicosvery?

Suresh: It's not necessary

?: You can do hash chains wrong in many ways, it's tricky. The hash
chain is being computed?

Suresh: In MN, only MN knows the hash chain, ARs know only the used
values and can verify the future ones when receiving FBUs.

?: Let's take this to the m-l. What happens when you use the same key
for generating an address and for the hash chain?

Suresh: That's why we have X, a random number calculated by AR.

7. FMIPv6 extension for Multicast Handover
   Frank Xia
   draft-xia-mipshop-fmip-multicast-00.txt               10 Mins

Mistake in signaling chart:
should be NAR buffers multicast  traffic

?: HI includes the multicast groups MN has joined?
Frank: Yes.

Frank: What does the WG think?

Vijay: Clarification, this is new work.

Vidya: I don't know if there is a problem here. FMIP provides a way of
delivering packets. Are you trying to prevent a new multicast join
message at NAR?

Frank: The multicast packets wouldn't be delivered.

Vidya: The context transfer is separate.

Alexandru: Multicast traffic is not moved by FMIP.

Vijay: Maybe it is time to use the CTX protocol, but that needs to be
done later.

?: Preventing joins is context transfer. Temporarily moving MC traffic
over FMIP traffic is a MC specific problem. Which of the two are we
talking about.

Vijay: The problem is how do we handle multicast traffic during FMIP
handoff.

Vidya: Can I rephrase: Part of the problem is how to deliver temporarily
multicast traffic to MN at NAR. This could be handled by a small
revision to RFC 4068. Second problem is how to prevent MC joins and this
needs to b addressed with other context transfer.

8. Hierarchical Mobile IPv6 Mobility Management (HMIPv6)
   Hesham Soliman
   draft-soliman-mipshop-4140bis-01.txt        

Vijay: Two comments, to which node is LBu destined?

Hesham: Source-routing could be used or a hop by hop option.

Vidya: What information is the AR changing?

Hesham: The LBU is is end to end, it is used as a trigger with extra
information in addition to BU in the packet.

Jari Arkko: This sounds like a micro optimziation

Vidya: Agrees, not sure that this is necessary and probably shouldn't be
done at IP layer.

?: Not sure that this is too much of an optimization

Vijay: We will continue with this in tomorrow's session.

Vijay: End of tomorrow, what we want to do with HMIPv6 security.

9. Handover Key Hierarchy for HMIPv6
   Hui Deng
   draft-deng-mipshop-hmip-hhokey-00.txt                  5 Mins

Shall we consider handover keying to HMIPv6?

Vijay: This would fit better with hokey.

Vidya: Right now not in the charter of hokey.

Vijay: Let's discuss this tomorrow with HMIPv6 security discussion.

_______________________________________________
Mipshop mailing list
Mipshop@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop