PCP Session 1, Tuesday 30 July 2013, 1300-1500 Chairs: Reinaldo Penno, Dave Thaler Notes: Paul Selkirk, Stuart Cheshire Welcome, Agenda bashing (10, Chairs) ------------------------------------ Dave Thaler called for additional reviews of pcp-nat64-prefix64-02 and pcp-description-option-01. Simon: I've read prefix64, and it's good. Paul: will review description-option. AD Evaluation of DHCP options for PCP (10, Ted Lemon) draft-ietf-pcp-dhcp, draft-lemon-dhc-topo-conf Goal: determine way forward with draft-ietf-pcp-dhcp ----------------------------------------------------- Passed WGLC in PCP, but doesn't have consensus in DHC working group, because it's doing something in DHCP that's weird. Stuart: Talking in general terms about load balancing doesn't make sense in the context of PCP. To set/change NAT state, I have to talk to the specific NAT that has my state. Dave Thaler: Can typical DHCP servers return multiple IP addresses for a given option? Ted Lemon: Yes. Jaqueline Queiroz: I think option 64 uses an FQDN. Dave Thaler: Does this WG want to follow the guidance of the DHCP WG or stick with the current proposal? Dave Thaler called for a hum in support of four options: 1) bare IP address(es) [strong hums] 2) FQDN [silence] 3) specify two options, and let the DHCP server admin configure one or the other [weak hums] 4) keep what we've got in the draft, to heck with dhc [weak hums] Reinaldo Penno called tentative consensus in the room for option 1. Report on PCP Security consensus call (10, Chairs) Goal: determine way forward for PCP authentication -------------------------------------------------- Suggested background reading: http://tools.ietf.org/html/draft-resnick-on-consensus-02 "Rough consensus is achieved when all issues are addressed, but not necessarily accommodated" Chairs, with support from AD, called rough consensus for EAP-in-PCP instead of PANA. PCP Proxy (15, Dan Wing) draft-ietf-pcp-proxy Goal: discuss open issues ----------------------------- Dave: Ready for last call? Dan: We just announced rough consensus on auth, so let's wait a week or so for that to gell on the mailing list. Dave: Try for last call before next meeting. PCP Authentication Requirements (10, Prashanth Patil) draft-reddy-pcp-auth-req Goal: discuss open issues ----------------------------------------------------- Margaret Wasserman: Document should not go into details on cryptographic strength and user identity models. Do require algortithm agility, since cryptographic algorithms improve over time and we want to be able to take advantage of those improvements. Margaret Wasserman: It's time to wrap up this document instead of debating it endlessly. We should close the security requirements so we can move forward. PCP port set (15, Simon Perreault) draft-ietf-pcp-port-set Goal: discuss open issues ---------------------------------- Dave: Does this work with a non-port-preserving NAT? Margaret Wasserman: Is the port set offset always the difference between the base internal port and the base external port? Simon Perreault: No, that's just an artifact of this example. Margaret: Why use an offset rather than return the first internal port number in the response? Stuart: Agree with Margaret, easier to explain. Dan: We need an example in the draft to clarify this. PCP Session 2, Wednesday 31 July 2013, 1300-1500 Chairs: Reinaldo Penno, Dave Thaler Notes: Ted Lemon, Stuart Cheshire Updates to PCP (UNSUPP_FAMILY, etc.) (20, Stuart Cheshire) draft-cheshire-pcp-unsupp-family Goal: determine whether to adopt as WG item ---------------------------------------------------------- Stuart presented on the unsupported family error code. Dave asked for comments. Silence. Dave asked the group to hum if they thought this was work the group should do. There was a loud hum. He then asked people to hum if they didn't care, and got silence. He then asked for a hum from people who oppose doing the work. Again silence. Stuart then presented on the use of the nonce. Prashant: If a client can authenticate, it is legitimate, it should be read/write. You moved around, reauthenticate, get a new SA, should be able to read/write. Dave Thaler: You've accurately reflected some of the points we've made. For anybody else that's new to this, what spec says, if you have strong authentication, it doesn't say what you do with respect to checking nonces. This probably only comes up when you are not using PCP authentication. Stuart is really asking, should there be any change for people... so certainly one possible answer is we do nothing, leave it as an incentive to implement authentication. Prashant: Has to be done if you don't do auth Dave: The protection the nonce is granting for bogus client coming and stealing your stuff, you've forgotten the nonce, starts spamming you with traffic, deletes your mapping, etc. Some protocols verify source address, e.g. using return routability check. Or e.g. we know it's good because I know I am using BCP 38 and SAVI, so it's safe. My own preference would be to leave it as an incentive for people to do PCP auth. Tiru: what I was tryng to say is if enterprise already has those kind of ... somebody can do read/write. Dave: Dangerous to bake that into a spec. ADs put security DISCUSSes on that kind of thing. Charles Eckel: One of the things I was worried about, it seems like you have to wait until your mapping expires, so wouldn't that cause a problem to the session during that small period of time? Stuart: Yes, there is a small window, and the base spec puts a lower limit, 4s? on this renewing halfway to expiry, so that we don't send infinite number of packets in last second, there's a low bound. If the remaining lifetime is 6s, when it gets down to <4s, there's a little window there when you don't have a mapping, incoming connections may get a TCP reset. Charles: Seems like that could be a problem, not just that you need to be aware of it, but could have harmful consequences. Dave: If you don't remember all the nonces. Simon Perreault: Being able to spoof your address is not necessary to steal a mapping without a nonce check. If the internal address is shared with attacker, then attacker and yourself are seen as same IP address by PCP server. Dave: If you have two PCP clients running on same host can have same issue. Stuart will update document to describe race condition where mapping is briefly lost and then recreated with a new nonce. DS-Lite (10, Margaret Wasserman) draft-ietf-pcp-dslite -------------------------------- Francis: There is no consensus about plan on ... encapsulation mode. Only consensus is only one mode. Margaret: The consensus was to document plain mode only Dave: I believe Francis is correct, we moved the DS-lite discussion out of the base spec because we didn't get to consensus. Francis: Document should explain one of the two modes. Francis: So this is DS lite issue (Issue 4). This address must be in the prefix, because authorization is done by prefix, doesn't matter which address in the prefix, as soon as it's consistent. Margaret: But mappings are done based on IP address, not prefix. Suresh suggested mapping on prefix instead. Or document that if CPE changes addresses, weird junk is going to happen. The mappings that previously existed will no longer exist on this address. Do we need to resolve, or say it doesn't matter, or are we wrong that it exists? Francis: I propose that we change this to address is subscriber ID. CPE IP address is subscriber ID. Margaret: So it should remain consistent even after hardware change. Francis: Use subscriber id, all this complexities... Margaret: It's an IP address Francis: Yes, but also subscriber ID. Margaret: so you are saying choice two, require CPE to use consistent address Simon: I don't think you don't need to do anything. Imagine regular DS-Lite, regular AFTR. What will happen? Margaret: depends on whether explicit mapping. Simon: know what state is in the NAT. Either mappings are remembered, or not. PCP will return state in the NAT, will create new state if it's doing implicit mappings. Margaret: problem is existing mapping would not exist anymore. Reinaldo: not implicit mappings, but map mappings. If you have a server and ask for a long mapping so people can connect to you, CPE can change source IP address, you need a way to detect that or people will try to connect to you and it will be a black hole. Dave: That's not specific to DS-Lite, so doesn't belong in this document. Margaret: I guess it's specific to DS-Lite Dave: Then not out of scope Margaret: PCP server somewhere else, any time that NAT was changed and changed its hardware address, ad therefore exernal address... Francis: In case of DS-lite usually use DHCPv6 to get AFTR addres, so easy to give you address at the same time. Margaret: I would prefer not to define per-prefix mappings. Server should not trash mappings, if it does you're hosed, we need to say. Dave: I don't hear anybody who understands and disagrees. Is there anybody who disagrees who has an opinion? Margaret: Add: "If CPE doesn't use consistent address, it will lose its mappings." Dave: everyone OK? YES. Margaret: If you still have issues, please tell me. Margaret: We need to figure out where we are on plain vs. encapsulated. Francis: Want to have only one mode. They are not compatible. Dave: We did have consensus on the need to pick one. Margaret: We'll try to start list discussion on that one. Using PCP to Reveal a Host behind NAT (10, Tiru Reddy) draft-boucadair-pcp-nat-reveal Goal: determine whether to adopt as WG item ------------------------------------------------------ Peter Allo: The only PCEF is the GGSN, so there could be no NAT in between. Otherwise ok. Tiru: We are trying to say NAT could be here or here. Peter: The picture is not correct. Someone: It is for tethering. Dave: I posted this to the list, but to generate discussion here... Constraints here are: read-only, both ends managed by the same entity, and the information that you are getting is looking up information about what the 5-tuple is. I disagree this solution is the simplest way to do it because it requires changes in PCP, PCRF and NAT, but I believe this is already solved by the NAT MIB where PCRF is SNMP client. The NAT MIB has the same constraints of read-only and managed by same administrative entity, so can already do with existing BEHAVE doc. Do people agree with that? Is there still a need to do something in PCP given we've already solved it in BEHAVE? Tiru: I haven't compared. Francis: About your idea, only difference is lifetime, if lifetime is in the NAT itself or only inside PCP server. Dave: Lifetime is either already in the NAT MIB or else it should be. Gang Chen: Provide information, draft is making between IMC and IP address. Phone number, etc. is IMC. As far as I know, I think in the 3GPP arch you really mplement on GGSN, keep information both the IMC and IP address, assigned by GGSN, maybe worth investigating if mappings already here or should create such a mechansim. Tiru: Already explained. Diagram is wrong. PCP Anycast Discovery (10, Reinaldo Penno) draft-kiesel-pcp-ip-based-srv-disc Goal: determine whether to adopt as WG item ----------------------------------------------- Toerless Eckert: That will have PCP in the home server and the access node, you are not going to get a single address, so maybe one for first hop, one for second hop, if you are in HG, don't know your access node, won't be able to connect to first hop because you are already. Reinaldo: okay, need to think about that, assumed first server will know second. Stuart: I am not a fan of optional features, because when you say optional, question is for whom? User, network admin, OS vendor, because if it's optional to implement, then people won't implement, so no-one can use it. It can only be optional for one individual, not everybody. My concern is that complicating PCP clients is going to make testing more difficult, not going to get implemented, what we have now at Apple doesn't deal with multiple servers, dealing with partial success, etc. So that's my nervousness about exposing this. If they want to do load balancing, then it's responsibility of whatever vendor to coordinate and present the illusion of a single face to clients. Reinaldo: Margaret also pointed that out. Modules, that change, that optional thing, I would like to give people support. Can be removed. Dave: We have a working group milestone around server discovery. Doesn't say how. Currently DHCP option document does fit into that one. Doesn't require a milestone update to do alternatives if we have consensus. Within the scope of our server discovery mechansim, does the WG think we should specify an anycast solution? Dave Thaler called for hum for whether WG should pursue specifying an anycast mechanism. Modest hum in favor. Weak hum against. Dave: Ok then, authors should discuss, merge, etc. PCP Flow metadata option (20, Dan wing) draft-wing-pcp-flowdata --------------------------------------- Someone: Can a router know what is a real capacity? Are you trying to tackle this, or where router already sees the traffic available to its clients? Dan: We have protocoype on docsis, etc. We're trying to have one protocol apps and hosts have to implement PCP that talks into the network and says this is what I would like. Details of layer 2 and 3 isn't relevant. That's the abstraction we're trying to get up. Leave the L2 issues to L2 tech. Bill ?: The intent that I think here, a very lightweight mechanism, do what you can, sometimes that's nothing, something's heavy end-to-end control. We're doing that intentionally. Alesh Vital: Looks like l2 might be involved, see what's available. Dan: We can't talk to L2 nodes with UDP and TCP, we're leaving that to something else, bring it back to L3. Tiru: In 3GPP will signal flow data, 3GPP already has semantics, so mobile device doesn't have to ?? that would solve the mobile network problem that L2 ... Chung Hua, China Telecom: Why I want to clarify why access network here refers to L2 network, currently bandwidth is very big, so the bandwidth control is generally implemented on edge of IP network, not on access network, for some marketing strategy for network operators. Dan: My definition of access network is everything up to where my service provider starts... my SP's first L3 device. Chung: Everything can be done ...? Dan: I've been doing networking for 20 years, we have enough bandwidth now, but we keep using up all the bandwidth we have. We keep trying to solve the problem. This is a new approach, perhaps not necessary. As I said at the beginning is that we don't have ... I agree that if you have enouhg bandwidth, you don't need this, but there are a lot of networks where that's not true. If we have enough today, will we have enough tomorrow? Dave: Earlier you gave another piece of that, even if first hop is over-provisioned, next won't be. Really fast WiFi in house, really slow access to Internet. Dan: Smell-o-vision works on home network, but outside not so well. Not always access link, but if I know what the access link can give me, I know I will never do better. Chung: Second issue, PCP is related to port IP address sharing, but generally for service guarantee for specific service, public IP address of ruser can also need to send service guarantee mechanism, so requirement in your draft is very general. Dan: You're describing how a lot of content providers are prioritizing traffic today. Objects they want prioritized, they'll put on a certain CDN, certain IP address, pressure the ISPs to prioritize traffic to/from that IP address. That works. If you have that and that works, keep doing it, you don't need this. But the subscriber is not involved in that. These messages come from the subscriber. They are asking the SP to prioritize this traffic, and the SP says ok I'll try, or I will. Chung: Some kind of collaboration between network operators and corporations. Dan: With fixed IP addresses and operational overhead. This is ad hoc, subscriber wants prioritization of Skype over Netflix, etc. Can't use fixed IP address to CDN. Toerless: I wanted to say this becomes more logical thinking about there are more use cases than saying specifically I want to have this bit rate, e.g. in Homenet they have at least four different Internet connections, may want to choose one, may be bandwidth case, or other use case. I want to have display on tablet that tells me important traffic flows. What do I see there? Dan: To tighten that up a little, decide if flow should go over 3G or DSL, how much I want to spend, how fast I want to reach limit. Dan Wing: WebRTC PCP use case PCP for IPv6-enabled SIP Deployments (10, Jacqueline Queiroz) draft-boucadair-pcp-sip-ipv6 ------------------------------------------------------------- Dave: Who is intended audience of this document? Jaclyn: SIP community Dave: I'd prefer that the SIP community own this, and the PCP WG review it. Dan Wing: Sure I'll review it. It does seem to cite a bunch of non-WG docs now. Before bringing it outside, it needs to be toned down to lower level of reference or removed. It will make PCP look even more immature. Try to show the stuff that PCP can deliver right away, don't be too loud about the stuff we are working on. If the only benefit is stuff we are working on in the future, it would be better not to bring it to SIP yet. Dave: Good point Implementation report on Integrating PCP with (10, Reinaldo Penno) MiniUPNP daemon ------------------------------------------------------------------ Simon: Have you implemented client side? Reinaldo: Library has client and server. There is a basic PCP server and a full-featured PCP client. Aside from that, there is also an integration of our PCP server, a more full fledged one, with UPnP server. Dave: I don't think flowdata spec has a code point in it. How did you choose? Reinaldo: We just came up with one opcode, and there is also the provision, there is a functionality that some OS can't mark the server packets. Servers are per-domain architecture, so which marking should I use on this network? So through the flow data option you can say I am application X, use the code point, I am AFT1. Toerless: Dave mentioned UPnP interop? Dave: Did you implement UPnP interworking? Toerless: They are all ships in the night? Reinaldo: Yes. Implementation report on Integrating PCP with (10, Reinaldo Penno) Transmission Bittorrent Client ------------------------------------------------------------------ Stuart: Version 2 not supported, trying version 1. What is that about? Reinaldo: This is not the client, server saying don't support ... remember we had two versions of PCP? Dan Wing: Of course you're supporting v2 and deprecating v1, right? Analysis of Port Control Protocol in Mobile Network (10, Gang Chen) draft-chen-pcp-mobile-deployment ------------------------------------------------------------------- Tiru: I reviewed last version, it was updated based on my comments. I think we agreed on all the comments. But it needs more review from other operators. Dan Wing: Earlier you said for a similar draft, who's the audience, should it be done there? For this, audience is not PCP, but 3GPP, why not do it in 3GPP land? Or have the document here and tell them about it, or rewrite it in 3GPP land. Dave: Advice we gave to that one was we should endorse it and make sure it says what we want it to say, but let someone else publish it. If we take the same approach here, we need to have somebody else publish it where the audience goes to. Aresh: trying to show what are use cases for PCP mobile. Advertising. Dave: If the audience is authors of specs vs people who deploy. SIP case makes sense for people who are using SIP, not writing specs. Dan: I don't think we have a procedure, would need WGLC. Normally goes to IESG. We need to do WGLC, maybe do IETF last call, then have 3GPP publish it. T37, I wrote RFC for that, ITU wrote T37, that was two pages and cited the RFC. That is another way to accomplish it. Gang: Related to 3GPP arch already published. This is out of their scope, even that it is related, they would recommend to go to IETF. Margaret: We did the same thing, we wrote a document to 3GPP to offer them advice. It's weird to offer unsolicited advice. We do have a 3GPP liaison. There are two possibilities here, somebody woke up and thought 3GPP ought to do something. Another possibility is people in 3GPP need to know this. Liaison ought to ask WG to do this work. There are people who can do this, not heavyweight. We shouldn't do the work in the absence of a request. Gang: The recommendation in the draft isn't very related to 3GPP, it's related to NAT box and mobile terminals. So in that case, this one is deployed in mobile particular environment. Chung: I think this is issue of IP layer. I agree this should be above DNS. Dave: If this is only about NATs and CGNS, then it's not specific to mobile networks. Either these are generic or specific to mobile. At least terminology is mobile-specific. Gang: That is only in the background. Alesh: Would the WG be more confident or happy if it would be more than mobile? Just trying to sense where the problem is.