RE: [Mipshop] MIPSHOP Session I Minutes

["Vijay Devarapalli" <[e-mail]>]

forgot to thank Henrik Petander, TJ Kniveton and
Alexandru Petrescu for taking the minutes for the
first session. sorry about that.

Vijay 

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[e-mail]] 
> Sent: Wednesday, December 06, 2006 4:38 PM
> To: [e-mail]
> Subject: [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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mipshop
> 

_______________________________________________
Mipshop mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mipshop