FMC BoF Session on Tuesday November 6, 2012 at IETF - 85 in Atlanta Salon E 1700 - 1705 5 minutes Chairs Administrativia: Note takers, Jabber scribes Agenda. 1705 - 1720 15 minutes AD, Chairs Scope of BoF FMC Introduction PS Draft PS draft Brian Haberman: Non-WG forming BOF Will need more than just intarea Need to understand the problem statement Participate early, often "Our Architecture" A number of user devices, cellphones, smartphones, iPads, PCs Connect to different types of IP networks - heterogeneous access To enable seamless operation: when you handover, would like to go through a similar authentication so that experience is seamless. Previous meetings IETF83: Side Meeting 6 use cases presented IETF84: Side meeting 4 use cases Related drafts on use cases: draft-schott-fmc-requirements draft-xue-fmc-ps draft-sun-fmc-use-case Med's draft on hostid Scope of BoF Brian's advice: keep discussion moving forward Focus on addressing issues raised with proposed work items Get other presenters' opinions, get what you think, identify items that require IETF work and people to work on them. Proposed Work Items Group ID UE Mobility in Fixed Networks Med will propose HostID 1720 - 1735 15 minutes Dirk FMC Problem Statement Presentation PS draft "Our Scenarios" Different devices, laptop with WiFi, fixed screen at home, smartphone with both cellular and WiFi Can access his services, the Internet, whatever he wants via different access technologies. Can use the home WiFi, portable device, FTTH Cellular device can go via cellular provider or WiFi hotspot Services are quite different, can be QoS like Skype or best-effort User has one subscription to his operator/service provider, we should enable user to carry his devices anywhere "Our Architecture" Two kinds of access: cellular, Public wifi or RG/NAT, needs two kinds of services: operator services, Internet PS Use Case 1: Why Group ID? Service subscriber ID, can be used on multiple devices and on multiple access networks Keith Moore: each device has at most one subscription? Dirk: Keith: One operator per user? Dirk: yes one operator per user Sri: BBCF, other systems, 3GPP has defined S2a, b, c, why are we not discussing this in that context? It would help us identify the problem. Is this I-WLAN interworking based on S2b? Then, access network has nothing do with it. If you can bring in those reference points, we can identify the gaps in the access network. One way is to overlay IPSec tunnel on existing access. Another one is S2a for trusted access. To bring in NAT, need to state what your assumptions are. Dirk: we wanted to be as general as possible, just have a cloud here. Philip Eardly: work for BT, we are a fixed operator not a mobile operator. I think this scenario is not one that is relevant to us as a fixed network operator without a mobile operator. Is that correct? You've got the BPCF which is a 3GPP function. Roland, Deutsche Telecom: scenarios we will discuss later if you have only a fixed network or both a fixed and wireless. LiXue: there are 3 access models for WiFi access back to PS service. We didn't mention them here, because we need policy control as well as IPSec. It is not suitable work for IETF. Sri: at the end of the day, we are integrating with 3GPP system which they already defined. If you don't bring in that, how do you identify the gap? LiXue: IETF83 and 84, we mentioned those networks, now we focus on problems relevant to IETF DaveMCDyson, Verizon: should be able to place this more precisely re S2a. BBF working text 291, you are referencing a workshop from November last year. Need to do some work to find out requirements on fixed network operators too. BBF is writing requirements for 3GPP, would be nice to get some validation before considering chartering another working group in IETF. ADs trying to minimize new working groups. Dirk: mailing list began Nov 2011, we dropped Host ID, changed to Group ID. Will come later to the specifics of IETF. MarcBlanchet: host has some access to an enterprise network, take that node go elsewhere, then by some means I need to authenticate back to the border of the enterprise network. What's the difference? Dirk: that is the use case. We changed the access network, we need interfaces between the networks to exchange policies, authentication. Need some kind of ID that identifies the user with his subscription. MarcBlanchet: scenario I described already has some solutions. Doesn't need any further protocol work. Dirk: Are these solutions standardized? MarcBlanchet: VPNs... ? Dirk: not every user will bring up a VPN. MarcBlanchet: so you are putting additional assumptions on the access network? Keith Moore: why are you taking an easy mostly solved problem and turning it into a much harder and unsolved problem. Looks like a step backwards. Why should a service trust random networks to provide identification and implement its policy for it? You are entrusting the wrong party. Should entrust the host themselves. Dirk: not a random network, it is some network that has connections to the mobile network. Keith: so what you're telling me is that this is a less general solution than what already exists. Behcet: we are not considering VPNs, considering hotspots or home network Keith: you are adding complexity and doing harm to the network. Behcet: operators want it. Keith: what is the benefit to the Internet community? You are adding complexity to the Internet. Roland: don't think having everything in IPSec tunnels for QoS is less complex. If you have Diffserv mechanisms on the tunnel, you need to have hop by hop diffserv treatment. Tunnel for 3rd party user, then home user with a different diffserv priority, then better service for the customer in your WiFi hotspot compared to your home services. Keith: raise some interesting points, can't see how it doesn't add more complexity, question is is the complexity worth it. Dirk: Group subscriber identity, user just pays one bill. User can use different devices at the same time or sequentially. User can watch video on his smartphone, then switch to his home device. Philip Eardly: 3 kind of benefits, one about app switching devices, one about giving user one bill, one about something to do with service quality, get same quality no matter what technology is used at the edge. Can understand them separately, you are presuming one technology will solve all of these problems, but they seem like different things. Behcet: don't want to get into solution space, trying to define the problem. Dirk: have to see when we come to solution space. LiXue: First thing we need to do for policy, need to identify multiple devices belong to one subscriber. Same for common billing. Ahmad Muhanna: haven't read the draft, would like to listen to the rest of the story. Cannot jump to conclusions from one single slide. Dirk: Application for Use Case 1: Uniform policy control All devices managed by the same group, access service from home via fixed network, subscription may allow sharing bandwidth between multiple devices. Use Case 1: Protocol Issues IP Edge box in the fixed access network is the policy enforcement point, needs to look at the IP traffic, identify to which subscriber the traffic belongs to, can do the right policy and accounting. So Group policy has to be transmitted using some new or existing IP protocol . JulienLaganier: between which node and which node? Dirk: between the AP/RG and the edge router in the fixed network. JL: Why do you need to transmit this group ID between AP and edge? If edge node knows IP address for UE 1 and UE 2, then you don't need to transmit it. Dirk: transmit it according to the right policies. Sri: Julien's asking, when you did AAA, you know the device's profile, group IDs. Device 2 comes up, then on BNG there is subscriber state for both the devices, why do you need to carry? Roland: does it also work if there are different users with different group IDs behind the AP? Sri: thought we were excluding IPsec, there is clearly subscriber state on the IP Edge? T.Reddy: assuming there's a NAT, same IP address, cannot distinguish the endpoint. You want to do policy enforcement, is it just QoS? Dirk: depends on the service. Skype may work with best effort, but mobile operator service might need guarantee. T.Reddy: that info is not in the draft, going to enforce it at 5-tuple, IP-layer, or whatever. MarcBlanchet: may not like IPSec/VPN. Operator is offering video on demand access to next soccer/football game, available on the cellular network but not the WiFi network. People do that with high-level authentication such as web authentication. Don't need all this stuff. Seems that there are a lot of assumptions on the access network, some signaling by the home network router/devices, a lot of assumptions, whereas there are all kinds of ways to do this with a web service. Dirk: less effort if we use diffserv than if it's an operator service mic: Is the AP a NAT device? Yes. Need a group ID, packet doesn't have a group ID, how do you carry it? Dirk: then we cannot access or fully exploit the subscription of the user. Behcet: why would NAT remove a Group ID? We are talking about option field of extension header or something. JulienLaganier: disagree with "need to transmit group ID using IP layer protocol". What you need is to identify, on the IP edge, which packets belong to which group. Behcet: you said if every device authenticates, state on AAA would be there. However, if you just do WiFi authentication, device needs to tell its Group ID to the edge router. JL: that is solution space. Problem is to associate traffic to groups. Only an issue when there is an IPv4 NAT in the RG. If we don't have autehntication, etc. etc. We do not necessarily need to transmit this group ID. Junnan: a lot of assumptions about how nodes are attached to the network, what function is in the RG. This slide should present the assumptions and the problem. This slide focuses on a solution. We don't know what's happened before this QoS enforcement point. LiXue: given there is a NAT on the RG group ID will not be changed. You can have several solutions added to the IP packet of the user. Even if the RG has NAT Jean-France: trying to define some kind of identifier. Not clear what it is, who creates it, who consumes it? Cable networks already have well defined policy mechanisms. Roland: solution should also work for cable networks, not only for DSL. Behcet: policy architectures do not consider group ID of machines presently. T.Reddy: 3 networks, access, edge, mobile. No problem if there is no NAT in the RG. Is there a problem with v6? Behcet: yes. Problem is not related to address sharing. Problem is one subscriber having more than one device connected to the Internet. T.Reddy: if each device has an IPv6 address, we can key the policies off of that. Should clearly state what is the problem with v6. Behcet: not related to a specific IP address. A group of IP addresses, not one specific IP address, need to be given certain treatment. T.Reddy: all IP addresses have to be authenticated? Behcet: some devices may not be authentication. JonneSoininen: terribly confused. Trying to authenticate every single packet, to understand to whom it belongs to? Dirk: at least the first Jonne: then how do you know that the subsequent packets belong to the same flow? Sounds like you are trying to authentication packets. We have a mechanism called IPsec. Now you just have to use it. Not quite sure what you are trying to do here. Just putting an ID in there wouldn't be very secure. Behcet: group ID could be transmitted not in IP-level, could be ICMP, not in every packet. Edge router should know which packets belong to the same group so it can give unified policy. Jonne: isn't it like authentication to the network? RADIUS/AAA is that what you want? Behcet: coming from a group of devices, coming from an operator. Jonne: like I do with my WiFi. Group of devices with WLAN password. You are trying to do the same thing with arbitrary devices, arbitrary networks, convey that information to the IP edge, right? Dirk: some connection between the user and his provider of service Jonne: we have mechanisms. We have 1x on WLAN, then we have AAA mechanisms to convey that information to the network. What is the new requirement that you have here? Isn't this a normal network authentication problem? LiXue: there is already some similar Group ID in WLAN network such as E-SIM, password or something. In FMC there are multiple devices, will access service by different access technologies such as WiFi. When device has subscription to one operator, will have same uniform policy for their devices. Jonne: understand that point, unified service, just don't understand what is new here. Have multiple SIM, one solution we can use. Could use the same password/credential, what is the new thing? Why is this different from network authentication? LiXue: policy control, single billing Jonne: don't have to pay multiple bills for my 2 SIMs. We have solved this in 3GPP. LiXue: need to pay your residential subscription plus phone bill Jonne: not necessarily. LiXue: bandwidth sharing by multiple devices one subscriber Jonne: confused. Ahmad Muhanna: don't blame you. From first slide, understood there is a PCRF somewhere in the picture. Behcet: don't want to use 3GPP terms Ahmad Muhanna: if QoS is part of the problem, you cannot just say group of IP addresses. Normally QoS is applied on a per bearer. Behcet: maybe PCC needs to be modified. Ahmad Muhanna: multiple IP address, same QoS, how is that going to work? Whole problem boils down to when you have an IPv4 NAT, multiple devices behind it, coming to WiFi, multiple devices cannot be distinguished to apply QoS. Want to send a Group ID to say that this bearer behind the NAT is for this device not for that device. That's the whole scope of this problem. Spencer Dawkins: how many more use cases do you have? Dirk: one more, this is the first. Spencer Dawkins: feel like if we are talking to IPv4 packets going through a NAT, we are at a lower level than what we normally talk about with use cases. Suggest you put together one slide with clear problem statement. For the room, suggest that we let them get through the presentation. People can talk in the hallway later. JulienLaganier: want to resolve something first. On the IP Edge we want to attribute packets to groups. But you mentioned there might not be authentication. If there is no authentication, who decides which devices are in which groups? Dirk: service provider JL: if device is unauthenticated, how do you say the device is in the group or not? Is there authentication? Seems yes, service provider defines who is in the group. That should be written there too. David, Ericsson, liaison between 3GPP and BBF. There was a reference made to TR203, suggest we liaise the requirements or whatever we think are gaps, to the BBF, then have them come back with whatever new protocol mechanisms they think are needed. Use Case 1: Solution approaches Embed group ID in network layer. Subscriber/group ID can be transmitted in IP layers as option. New IP work is needed. Problem Statement Use Case 2: UE mobility in IP network Issues: fixed network does not track devices, don't know when device has left coverage. Application for Use Case 2: resource management. Protocol issues: fixed IP network edge routers need to signal connectivity status. One idea to extend CAPWAP. IETF work needed. Sri: agree that tracking devices when they move away from WLAN access is a valid problem. You are not showing your assumptions: layer2 or layer3 access, authentication there or not? Need to state the assumptions. With CAPWAP, is WLAN controller on BNG? Brian Haberman: want to make sure the proponents of FMC understand the feedback they have gotten. When I see different assumptions about what layer these should be at, raises big red flags. Seems like you have a solution in mind and trying to fit it into the problem space. Are the requirements you present next, is there an assumption that the solution has to be at the network layer? We just spent 55 minutes discussing something you had allocated 15 minutes for. You've got 15 minutes, then we can have open discussion. 1735 - 1750 15 minutes Roland FMC Requirements Presentation Requirements draft Roland Schott Operators like DT have hybrid access, fixed plus mobile, converged services on multi-access devices. Have the IPv4 NAT problem we want to address and solve here. Problem is about how heterogeneous access could be used, by different AAA entities and different administrative domains. UE identity handling, group ID handling, mobility across domains, link quality information for service adaptation and connectivity policy. There was talk about multi-SIM, that's in 3GPP, have Line ID, these auth mechanisms focus on specific problem, they are proprietary, Solution should also be valid for operator that has only an IP network with LIPA access. Group Identification: need to enforce unified policy for different devices. Authenticated, enforced by the operator. User/subscriber ID should also be accessible to 3rd party services and applications. Can correspond to multiple device identifiers. Requirement #2: user mobility mobility between WiFi and 3GPP, mobility within WiFi Seamless HO, qos policy, connectivity status should be reported to IP edge router. Slides showing group ID from access to edge, connectivity status to the fixed IP network. Charlie: for the group ID, what happens if someone has two devices with the same group ID, can they use the network at the same time? Roland: same group Id, different device IDs. Charles: using the network at the same time? Roland: some policies ok, some may be like traffic shaping. If you have multiple devices like laptop, mobile phone, policy should work at the same time for both when connected over same WiFi access. Charlie: is Group ID supplied only when hooked up to WiFi, or is it also supplied on LTE? Roland: difficult to do in LTE? Charlie: are they going to change the network attach procedure to include group ID? Roland: that is solution space, need to weigh costs and benefits of our protocol work. Charlie: what if AAA knew that these devices were part of the same group, AAA could then identify? Roland: Think about GSMA rich communication suite, switching to WiFi authentication is a challenge. Behcet: edge router has to do this. AAA may know this, but edge router needs to do this. Charlie: talking about changing edge router to handle group IDs? Behcet: yes. Jonne: You said you wanted to use IMS over WiFi. Seems like you are wanting to do application-level authentication at the IP layer. Don't think you have an issue here. Roland: if you have only IMS devices, maybe not, but what about devices that are not IMS compatible? Jonne: you said one of the use cases was to authenticate to IMS, now you are saying how to authenticate to an access network. We already have a lot of protocols that can do that. Are these requirements to a mechanism or to the ID itself? Behcet: please go to the list. Jonne: trying to help you now. Want to understand what you are actually proposing? Are you trying to solve the network authentication problem? Are you trying to define a new ID? Why doesn't NAI work for you? Or are you trying to solve application authentication? Roland: main thing is the QoS problem. Different devices, want to get the QoS from a converged BNG/PGW. Jonne: don't we have 3GPP mechanisms for authenticating to WLAN? Roland: based on tunnels? Jonne: yes. Didn't see a requirement that said use no tunnels. Behcet: requirement coming from China Telecom, which is mobile and fixed. Jonne: can you explain why you can't use tunnels? Didn't see that in the requirements. 1750 - 1800 10 minutes Med UE Identification Issue Presentation Host-id draft 1800 - 1810 10 minutes Sri Service Provider Wi-Fi Services Over Residential Architectures Presentation Additional Requirements 1810 - 1825 15 minutes All Discussion Use cases Brian Haberman: how many people understand these use cases? <5-7 hands raised> Ahmad: yes, but there is no match between my understanding and this? Brian: no need to ask the correlary question, can just do inverse. No need to ask about the requirements. Suggestion is for the proponents to take this feedback, use it to define what it is that they're looking at and come back with a clear problem statement. You also referenced other standards bodies. Sri: I do believe there are some gaps, however, they are not stating the assumptions, they are keeping things vague. That is the root problem. Jari Arkko: advice to the proponents is they need to take a fairly big reset, small tweak will not do. In addition to use cases, what layer are we talking about? Are we in the right standards body? There are a fair number of protocols that have capabilities for identifying things, can even add new attributes for these things. Big reset, big re-think is called for. Brian Haberman: OAUTH popped up. Jari: FMC is a big important topic, there is important work to be done in that space. Junnan: depending on the assumptions, we will have different solutions. First point is to clarify the requirements and use cases. David from Ericsson: strongly suggest the use cases be brough to the broadband forum so they can be reconciled against what has already been done. 1825 - 1830 5 minutes Chairs/ADs Conclusions and Next Steps Reading List http://tools.ietf.org/html/draft-xue-fmc-ps-03 http://tools.ietf.org/html/draft-sun-fmc-use-case-01 http://tools.ietf.org/html/draft-schott-fmc-requirements-04 http://tools.ietf.org/id/draft-boucadair-intarea-host-identifier-scenarios-01.txt http://tools.ietf.org/html/draft-gundavelli-v6ops-community-wifi-svcs-05