Re: [MIPSHOP] IETF#63 Minutes

Thanks Stefano. 
Folks, sorry for the delay, but we both had personal reasons that kept us away.
We don't have much in the minutes for James' SeND keys presentation, so if anybody
remembers or took notes, please send them in.

tnx,

-gabriel

--- stefano.faccin@nokia.com wrote:

> Hi,
> please find enclosed the minutes from IETF #63. Please review and comment ASAP. They
> need to be submitted by EOB Friday September 2 (17:00 ET).
> Thanks,
> Stefano
> 
---------------------------------

Mipshop Meeting   sfaccin  sfaccin  3  130  2005-09-01T21:50:00Z  2005-09-02T04:32:00Z 
2005-09-02T04:33:00Z  7  2877  16403  NOKIA  136  32  20144  9.7616        17    0  0    

Mipshop Meeting

IETF 63, Paris, August 2, 2005

Meeting Minutes: Christian Vogt, TJ Kniveton (merged by StefanoFaccin)

Tuesday, August 2, 2005

0900 - 1000 Morning Session I

1.Preliminaries --Gabriel Montenegro

Agenda bashing

Bluesheets and notes takers

Grouphas a new co-chair: Stefano Faccin

2. Document Status --Gabriel Montenegro 

FMIPv6 has received RFC number  this isthe first RFC for the WG

3. FMIPv6 MN-AR security: SeND-based Handover keys

     draft-kempf-mobopts-handover-key-01

     James Kempf

James on SeND keys for MN-AR

·        usage: for FMIP, for context transfer

·        use send CGA RSA PK to encrypt a handover (ho) key, 

·        how a ho key is used depends on ho protocol

·        name of key is the addr

4. Mobile IPv6 Fast Handovers for 3G CDMA Networks

draft-yokota-mipshop-3gfh-00.txt

Hidetoshi Yokota 

MIPv6 to be used in 3G network.  Need seamless handovers, therefore fasthandovers.
Typically, MNs will be multi-homed and use differentinterfaces.  This allows for smoother
handovers.Bicasting during handover.

Christian:  Bicasting might confuse protocols at upper layers, like TCP...

A: There was a draft in Mobileip working group using the eifel algorithm tocope with
packet duplicates and out-of-ordering.

Rajeev: Planning to build experimental testbed?

Yokota: Yes.

Q: How bad is a handover without FMIP6? Right now, we can do it at layer 2, but standard
MIP6 won't be efficientenough.

Q: Seems that you need additional messages...

Rajeev: When you use FMIP6, you can skip some messages, namely the ones shadedblue in the
presentation.

Q: How about layer-3 information inlayer-2 messages?  Is this possible?

A: Yes.

Q: Would it help?

A: We can skip some layer-3 messages.

Q: The trigger seems to always come from the BS.  Is this always the case?

Yokota: If the MN loses connection, MN can trigger handover as a fall-back.

5. Mobile IPv6 Fast Handovers over IEEE 802.16e Networks

draft-jang-mipshop-fh80216e-00.txt

Heejin Jang 

IEEE 802.16e handover process consists ofpreparation and execution (2 steps). For the
purpose of FMIP6, we extend this to four steps:new-access-router discovery, handover
preparation, handover execution, andhandover completion.

Charlie Perkins:  Assume a handover is successful, but there are no packetsbuffered. 
Since you don't use NACKs,how does the MN know that the handover was successful?

Rajeev: There should be an FBACK in the successful case.

Suresh: What kind of delay would you have, e.g., with EAPoL?

Alper: There are other optimizations. You can authorize several base stations at once to
reduce the delay.

Tuesday, August 2, 2005

1030 - 1230 Morning Session II

6. Hesham Soliman:  HMIPv6MN-MAP Security

        No draft yet. 

        Hesham to lead discussion on alternatives and issues.

Current scheme relies on IPsec between theMN and MAP, but RCoA is not reserved to the MN,
and there is no binding betweenaddress and MN.

The current IPsec solution works. 

Issues raised: shared keys are not anoption; certificates not easily deployable on the
host (due to no standard wayof managing certificates) and do not work with AAA.

Alex Petrescu:  How about certificates on the AR?

James Kempf:  Security protocols with host-based certificates have not beensuccessful.
Cable networks use them, but in general it is a problem.  EAPTTLS with server-side
certificates aremore widely used and deployable. Another reason, as discussed in netlmm -
ifyou get a virus or spyware on host, virus could distribute address of MAP. 

Which model:  authentication only, or both authentication/authorization?  Current draft
considers both.

When using certificates:  Authentication only => Certificates areonly used for setting up
a key.  This issufficient everywhere where mobility is a default service.

Authentication/Authorization => different.  This is needed if mobility is an
add-onservice (roaming scenario?)

When using AAA:  It is transparent to the MAP whether the MN roams or not
becauseauthoentication and authorization are entirely handled by AAA infrastructure.

CGAs could be used in theauthentication-only model, but they are not that useful in
theauthentication/authorization model.

Suggestion:  Keep current IPsec as default. Add other mechansims, as we know what the
problem and scenario are.

Greg Dailey:  Wondering why you would not use IKEv1 in agressive mode withpreshared keys.

Francis Dupont:  You should just refer to the PKI for the certificate version.

Gerardo: As of now, IKEv2 and EAP could also be used.  This is what we had done in MIP6
bootstrapping.  Certificates is one option, IKEv2 and EAP isanother one.

James: Only minor difference with dynamic HA deployment.  So current HMIPv6 to PS not
wise.

AA: What do you mean by keep the currentmechanism?

Certificates? EAP support is not there inthe draft.

Hesham: When this draft came out, therewas no IKEv2.

James: w/ regard to 3rd bulletpoint: Wesee a minor difference b/t this and dynamic home
agent assignment (inbootstrapping draft). I don't support moving this to PS. We'll never
deploy w/dynamic home agent assignment 

Vijay Devarapalli: This is similar toassigning HA on visited link. Security for that is
hard. Not possible to havecert for each MN, for each MAP. So I agree w/ James.

Hesham: There is aggregate trust b/tdomains. So it's not for each MAP.

Vijay: You can't authorize MAP in visiteddomain.

Hesham: This is chain of trust -- CA invisited domain trusts CA in home domain

Vijay: We don't have something like thistoday

A: yes we do, PKI

Hesham: Point James made - if we havedynamic home agent mechanism we don't need this. But
we don't have one today.

Vijay: When you do local HA assignment invisited link, you have to set up security, so
that solution would be applicablehere 

James: We've discussed this, and it's notentirely as easy as you've made it.

Shinta Sugimoto: You mentioned a schemefor MAP to verify uniqueness of rcoa of MN. in
draft, it mentions that thatwill be used, but when MN is away,...

Hesham: it's internal -- you check BCache,and if one already exists, you don't use it.
It's just a way of checking forduplicates.

Sugimoto: It should be done in initialBReg.

Basavaraj Patil - On last slide, how toproceed  in order to keep complexity of MN
minimal, we should use samemechanisms for base. on 2nd draft for ..... (talking way too
fast totranscribe) stick to that, and don't worry about adding new security mechanisms

7. Applying Cryptographically Generated Addresses and Credit-Based Authorization to
Optimize

    Mobile IPv6 (OMIPv6)

    http://www.ietf.org/internet-drafts/draft-arkko-mipshop-cga-cba-00.txt

    Jari, Wassim and Christian

Goals for improving RO: Makeauthentication faster, but still infrastructure-less. Avoid
delays of CoA testsby doing them concurrently. Incorporate ML discussion and reviews.

Main ingredients: CGA, credit-basedauthorization for concurrent coa tests. During initial
handshake, normal returnroutability, and info is bootstrapped for subsequent optimization
(still oninitial exchange slide)

Peers have established BCE with 24 hrlifetime, extended sequence #, semi-permanent
security assn (all valid for 24hours) on "How Subsequent Exchanges Look Like" slide

Alexandru petrescu: There were only 2messages before, and now there are 4. Why would this
be quicker?

A: You have 6

Alex: Well during initial exchange yes.But now in subsequent excahges you have 4

A: You have 4 here instead of 6 in MIP.But you can use new CoA already after 2 messages,
but it is unverified at thattime. 

On slide "Where Credit-Based Authcomes into play" (describing how credit-based
authorization works). Canuse address up to a certain data volume, before it is verified.

Last slide: Have re-written credit-basedauth to make it more clear.

Vijay: I don't understand why you needextended sequence #s

A: Key used for computing Binding Authdata option can be used for longer time, up to 24
hours. Seq nos increasingduring that time, and they might roll over.

Charlie: That's a new coa every 2 seconds.Might suggest a different value.

Vijay: 2nd question: if BC on CN expires,then you need to do initial handshake to HA
again. Every time you do a freshregistration w/ CN again, you do 4 message handshake to
HA. With CN,

might not have extended communication. Soyou end up doing handshake w/HA each time. Some
of the advantage is lost.

A: When you are still w/in 24 hours, CNstill has shared key, so you will do an optimized
"handover"(re-registration)

James: This looks really good. 2questions. Technical: If CN doesn't understand this
algorithm, it can fallbackto return routability. So how do you prevent bidding-down
attacks?

A: in that case, CN would say it can doauth, but ...

James: A lot of IPR on CGA, and IPRrelease for SEND doesn't apply to this. So WG and
chairs need to decide onthis. Ericsson has released it, but MS hasn't, so they need to
release on this.

BB: Bidding down can happen, but it's notreally an attack.

Hesham: On a high level, I like the idea.But how do you earn credit in real
implementation?

A: By sending data to CN.

Hesham: No matter the content?

A: IP traffic. You want to prevent CN tosend more data to unverified address, to avoid
amplification attacks.

Hesham: Earning credit doesn't mean youare "[?]"

Francis: Size of ? is 550. So you need away to have larger options. So we have to fix
this problem somewhere.

A: So option space is insufficient?

Gabriel: Please send that to the ML.

8. FMIPv6 MN-AR security: AAA-based Keys

draft-vidya-mipshop-handover-keys-aaa-00.txt

Vidya Narayanan:  

Same problem statement as James'spresentation with SEND, but we're trying to solve it
using AAA

Concept is handover master key sharedbetween MN and AAA server

Rajeev: I see it's an optimization and youcan do it, but why?

A: Useful when MN is rapidly betweensubnets

Rajeev: What timespace are we looking at?1-3 seconds? We should understand that part
better.

A: It really comes down to how the IPnetwork is deployed. Example: MN is driving down a
street and at every 4-wayintersection, there are APs on different subnets. Something like
this will helpwhen you are changing subnets frequently. We couldn't come up with a reason
whywe shouldn't do this. 

Rajeev: It's good to have, but maybebetter to have the base thing well specified

Rajeev: You have AAA MN nonce. Have youthought about MN generating nonce so it can
challenge network?

A: It was there, but we removed it.Question: what value is it adding to have nonce from
MN side? If we need to addit in, we can.

Rajeev: In AKA system, you have mutualauthentication.

CC: Pre-authentication information. Iagree it can help obtaining ? ,. there are 2 layers,
using 802.11i,... Whichare you using?

A: Protocol for deriving network key notrelating to network access at this point. Not
pre-auth as defined in 11i. 1stmessage from MN to AR1, it can send an HO request to AR2
while it's attached toAR1.

Hesham: Comment on what Rajeev was saying.There are some measured results where you end
up with handover every 3 seconds(Gabriel: let's discuss this offline).

Hesham: Next slide ("SalientPoints") - have you considered using Context Transfer? It's
not asbeautiful security-wise, but you can have one handover key

A: This has been beaten to death, and it'snot considered secure enough. This is really a
single round trip with every AR,and it's not in the critical path. You only need HO key
when you're about tosend FBU to old AR.

Hesham: Depends on what requirements areon performance of HO. ..

Continuing with slides. "Mailing ListDiscussions"

James K: I agree it is more complex.Problem is you're asking that AR have security assn,
and be aware of accessserver. In roaming, only NAS has this security assn. But the AR and
AAA serverhave to know about eachother. This is extending AAA infra in a way that's
notcurrently deployed. So unless NAS is colocated with AS, you have to upgrade theinfra
and deployment to establish that relationship. So I'm not sure how muchleverage you get
from AAA with this scheme.

A: Leverage is that you don't have toshare any other key with AAA server than what you
already have for EAP. 

James: In terms of managing network andsetting it up, that's a minor thing. If we could
do this without AR having toknow about foreign AAA server, it would be good. With
enterprise, it would workfine. But for roaming situation it would be harder. 

A: Today with roaming, AAA-L acts as aproxy.

Hesham: So you have AAAH, AAAL. I thinkyou're making it more difficult for yourself than
it is. If you're generating akey, and you transport it in RADIUS, I don't understand what
the problem is

A: Between AAA server and AR? That'sexactly what we're doing

James: ends up on NAS and not the router.

Hesham: You authenticate, profile comesdown, and you attach that

A: Tying this protocol closely to networkaccess.

James: Sounds like you haven't read thedraft. I was trying to figure out a way to derive
the key from AAA 

Gabirel: continue on ML

9. Neighborhood InformationElements Discovery (NED)

draft-kempf-mobopts-nhood-discovery-00.txt

Rajeev Koodli

NEDprovides a generic protocol for carrying information elements of interest toIEEE
802.21. E.g., FMIP, CARD, IEEE 802.21 are information services, but arenot harmonized. 
Protocols servedifferent purpose, yet share NED in common, but use differnet message
formats.

Need NED query-reply in a transport-independentway.

Ajoy Singh:  Are you re-inventing CARD? 

Rajeev: You resolve L2 identifier tosomething more useful for L3. No service attributes. 

Ajoy: We could have extended FMIP or CARDto do this. When CARD was designed, we wanted to
provide this mapping, and getinfo from network. Request and response are the same as
CARD. It was designedto get info about access network. 802.21 also defining this
protocol.

Stefano: Let's talk about 21 later.

A: Transport is client-prtocol specific.CARD uses ICMP.

Rajeev: Card uses ICMP; we want transport indepency.

Ajoy: You can use ICMP, but you can use others.

James: I responded to you on ML and gaveyou 5 reasons why CARD is unsuitable. I was WG
chair, and I still think it wasunsuitable.

If information element is described in XMLformat, do you think it should be combined
into? In this protocol?

A: Message structure followed by TLV. Eachoption has its own data part. You can define
your own structure in the datapart.

Suresh: Why did you want to model thisafter EAP? You're limiting yourself to 255 octets
of data.

A: Good point. We wanted the multipleprotocols listed to use it. So we have to live with
that limitation.

James: It was an architectural sense. Wewanted people to use it in different ways as
mentioned.

10. Media-Independent Hanover Services and Interoperabilty

No draft

Ajay Rajkumar, 802.21 WG Chair 

Brief background of what 802.21 is doing:handover enablers between 802.3/11/15/16 or
802.xx and 3GPP/3GPP2 or btw.802.11 ESS. Focus on:

- Adaptation to new link at L2

- Address continuity at L3

- Application continuity

Requirements:

- transport requirements

- protocol requirements

Hesham: Started talking about protocolsand architectures. What was the discussion that
lead to making this on alower-layer protocol instead of upper layer? If it was
independent, shouldn'tit be independent of link layer? Carried inside MAC layer?

A: No, this is for the L3. Separate L2requirements to discuss in another forum

Alex P: You are developing an L3 protocol?

A: These are specifically for L3 andabove. So transport would be L3. And protocol would
be carried in L3

Q: Why is this presented here?

Ajay: This is of benefit for layer 3 and the transport will be layer 3.  Messages can
carry layer-2 information, butthat would only be static information, not dynamic like for
instance signalstrength.

Hesham: Can you carry L2 information inL3?

A: Yes, it could carry L2 infomation whichis static, that is from information server

11. Examples of Information Services

SomeRequirements for a Media Independent Handover Information Service
-draft-faccin-mih-infoserv-00.txt

Greg Daley

Example Scenarios for InformationServices. These are personal ideas, that might help
people visualize things.Once pictures have come up, we can take questions. This is not
the 802.21group's view, but my own view.

Q: When you say IS server, what do youmean?

A: This is not a single cell or IP subnet.Enterprise domain or service provider.

Q: (on "Example IS entities") Soyou have 3 components. One in mobile, one in access
network. ...?

A: This is not any single access network.So it may not be on one single hop, IPv4 subnet,
or IPv6 link. So may beforwarding from mobile into access network. Could be on access
router, accesspoint, server in the network.

Alex: could you be more specific onrelationship between this example and work within this
WG? For example, wouldFMIP be applicable here? Media-independent is like saying IP. 

A: an implementation on a host, withmultiple interfaces and maybe multiple media. Media
independent b/t upper andlower layer protocols. Maybe useful to have media-independent
informationelements for 802.16,802.11,802.15, cellular. That can be transported in case
of

event services or info services in L2frames. But you may not want to deploy like that,
but transport informationservices in IP-like

Q: Do you restrict that client can notcontact server directly?

A: may not know server.

On last slide, need to figure out how todiscover where information server is, and
establish security assn with serverwhich allows transport to occur. May be NED, XML, ...

Q: do you have to add SRP record for DNS?

A: We need to check that it's valid andsecure.

Suresh: Circular dependency. If it's L3,we might end up with reactive handover, and we
need discovery phase in the 1sthop.

A: Implicit assumption is that there is anexisting connection, in the same way you get a
proxy rtr adv. You need an IPchannel w/ existing network. This is not a realtime service.

Q: if 1st hop NMI does not haveinformation, then how is it retrieved?

A: with redirection, you have tore-establish sec assn. If you have an SA, the other guy
may be able to get itfor you.

Hesham: Followup on Alex's question. Sincethis is abstract, what does it have to do with
us? Are we defining subset ofthis relevant to mobility?

A: It is particular to mobility. It'ssupposed to support ip mobility, i.e. in DNA there
may be add'l info that L2passed up. It's here because it has info in common with CARD,
FMIP, which areunder assessment here.

Hesham: So can we call it mobilityinformation service? 

A: Maybe we need mobility independent blahblah blah...

12. Rajeev Koodli:  FMIPv6bis (no slides)

We got an RFC # (applause). Those who stillhave references to -03, please update to RFC
4068. Moving forward, issuetracker for bis version.

FMIP6 is currently experimental.  Everything we have so far is experimental
orinformational.

IEEE 802.21 could provide a trigger for afast handover.

13. Gabriel:  Discussion ofCharter Items

Proposed:

- OMIPv6 + CBA

- HMIPv6 security and revision

- Information Elements discovery and IEEE802.21

- FMIPv6 security and revision

  -SeND-based keys

  -AAA-based keys

  -protocol revision

- Informational documents?

Ajoy: Can we have comment on how CARD doesnot solve problem? CARD could also do NED

James: Please write a draft to convince us.

Stefano Faccin:  Let's define requirements first, and then analyze what isavailable,
including CARD 

James: Are you going to write up a charterand post it to the list?

A: Yes. Most important things aredeliverables.

Gabriel: Thanks to all presenters. Pleasesend presentations to chairs.

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

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