Mobility for IPv4 WG ======================================================================= TUESDAY, November 10, 2009 1300-1500 Afternoon Session I Cattleya West ======================================================================= CHAIRS: Henrik Levkowetz Pete McCann AGENDA: 1. Preliminaries 10 min Chairs - Blue sheets - Note takers - Jabber scribe - Agenda bashing 2. Document Status 15 min Chairs draft-ietf-mip4-generic-notification-message-08.txt - Lots of IESG comments on motivation. Discuss today. draft-ietf-mip4-nemov4-dynamic-02.txt - We will issue a last call on this soon, but it has lower priority than 2006bis. GT> New version -03 is now available. draft-ietf-mip4-rfc3344bis-08.txt - Still working on the shepherd writeup. Will be submitted for publication soon. draft-ietf-mip4-udptunnel-mib-01.txt - On hold waiting on 2006bis; then we will issue WGLC. draft-ietf-mip4-rfc2006bis-05.txt - Ready for last call. Will issue soon. 3. Generic Notification Discussion 15 min Chairs + ? draft-ietf-mip4-generic-notification-message-08.txt Henrik> short presentation… Jari> I do not think we need a new doc on this or even an expansion of a section. We just need a convincing story to IESG that can be sent in e-mail. Is there some vendor or application that needs this, is there something in the pipeline that uses this Peny> In 3GPP2 they use such notification. The access GW is using this notification to check availability of resources. Jari> And is this draft explicitly referenced in the 3GPP2 document Peny> Yes Jari> The first order of business is to convince the IESG that this is needed. But then some of the other issues regarding appropriateness, incorrect use etc, that have to be dealt with. Henrik> My reaction to this, was that we could require specification before we assign numbers, so it is no free for all Sri> This provides a template for such messages. If you do not expect future extensions then it is waste of recourses but this technology might survive for long time in which case use cases will be needed. Lars> Jari asked me to be here…I am not an expert in MIP4 but I always feel nervous when we create a free form mechanism which allows anyone to do anything. It is easy for the IETF to do this but we have no control over what people do with it. How do you find out what do you need to interoperate Henrik> So what if we require specification before we assign numbers Lars> Yes the nice thing then is that you can check if the proposed use makes proper use of the extension. Also the other two RFCs mentioned are not as generic. Sri> We already have vendor specific extensions that are very open Henrik> MIPv4 always had very open standard and Vendor specific extension. Vendors implement vendor specific and some times bring it to standard later. But MIPv4 does not have a generic notification and if we had it we would be able to do the binding revocations based on that. So you are right that we should not let it be free for all. Lars> But why use a generic mechanisms if you can use a specific extension. Kent> Agree with some of the discussion but the context is not only generic notification. There is a lack of a mechanism for the HA to initiate signaling. George> There reason for a generic message is to have a common framework for use cases that come up in the future Lars> but this is a not just a message format is also changes the direction of the messages since now for the first time the HA can initiate a transaction Charlie>If we do not have specific driving for Jari>So what is the bar for requiring something generic? The 3GPP2 case is one do we need more Lars> One case is good, but lets define the specific use case, as opposed to defining a generic one. Henrik> but when we did revocation we hoped we had done the generic Henrik> first Lars> but I do not know how much trouble that was. I can see both sides of the argument. Doing it generically because it is easier but also loosing control it might be dangerous. I am just concerned with the protocol extension since I have seen in other protocols damaging extensions happening in other places based on something like this Henrik> Would it work then if we require specification for assigning numbers? Kent> Probably agree with this. We can also use this for host configuration and to signal the mobile router prefix; i.e., to change the context of the registration. Lars> so these use cases sound reasonable but also sound like they should be documented. One idea would be to define it as a message from HA to MN in some context and if you want to use it describe it in a protocol and we will give you a number for it. Hui> Since this message is sent by the network it is very secure George> so, just because it comes from the network is secure? Jari> We did not have a lot information during the IESG review. Now we have 3GPP2 use case and some examples from Kent, combined with require specification for assigning numbers is a better story that we should put again to the IESG. 4. Home Agent Assisted Route Optimization 15 min Antti draft-makela-mip4-nemo-haaro-05.txt Antti> Short Presentation… Some discussion between Kent and Antti regarding the size of messages and the use of compression for supporting large numbers of networks Henrik> But for experimental, is this a show stopper? Kent> Well if this needs to be implemented I am not sure. Antti> the use case for this is not to be able to do it across the Internet but only inside in a network Kent> I would say that this is even in the context of a given HA which means 1000s of routes Antti> 1000s maybe ok but 100.000s certainly not ok Raj> We have seen this a few times and I think it would be good to make it experimental Sri> What about doings this on MIPv6? Antti> Jouni and I have some plans to work on that Jouni> I think Sri was asking if you can apply the same thing for MIPv6 Jouni> NEMO Antti> I think yes, since now the IPv6-nodes are not required to support CN; so the discovery mechanism seems relevant but some other parts maybe not. Kent> this will become a WG item then? So it will be open to new ideas for scaling? It also needs some work on the NAT support Antti> yes it needs some more work Pete (from jabber)> This is in the charter already but we need WG agreement to adopt this as a WG draft Charlie> If this is going to be a WG draft I would like time to read it, since we did not know we had to think about this in these terms Henrik> OK, so lets give it 2 weeks and we will check on the list. 5. GRE Key Extension 15 min Parviz draft-mip4-gre-key-extension-00.txt Parviz> short presentation… Some discussion on treatment of G bit between Kent, Henrik, Parviz. Will be dealt with on e-mail George> You should probably use Long instead of short format Parviz> Yes, we received this comment before, will do. 6. Multicast / Broadcast Delivery Style 15 min Basavaraj draft-chakrabarti-mip4-mcbc-04.txt Raj> short presentation… Henrik> Unless there are any comments you should submit this as WG doc, since we had agreement already in last IETF. 7. IPv6 Migration support in Mobility Architectures 10 min Sri draft-gundavelli-softwire-gateway-init-ds-lite-00.txt Sri> short presentation Charlie> Is this specific to MIPv4 Sri> No it is applicable to mobility generally, I will ask the AD to Sri> sponsor it Charlie> I have another proposal based on source address NAT, which solves more problems Alper> How is this different than using PMIP? The softwire could be set up with PMIP Kent> There is no signaling currently. The scheme allows the option of signaling but more WRT to NAT configuration as opposed to the tunnel setup. DSLITE also requires no signaling. The CGN just decapsulates and does the NET binding Alper> But somehow the CGN needs to know how to forward the packet Kent> it is done like in DSLITE Raj> for MIP4 the access is IPv4, how does that apply?. If the addresses are overlapping in the HA how do you forward? Sri> based on GRE key Raj> of course private address are not really a limiting factor it depends on how you set up your network Kent> Yes you can use double NATing but it causes problems which is why DSLITE came about. Raj> double Nating is one approach but you can also zone the network etc Jari> how does this affect DSLITE? Requires any changes to it or is this just a use case? Sri> here we are using GRE encapsulation which is not currently supporting in DSLITE, and then the forwarding is based on the IPv6 address+GREKey as opposed just to the IPv6 address. Jari>So I understand the DSLITE use case but why are we doing this here? Here we have the access GW which terminates thousands or millions of subscribers. There are some issues with overlapping addresses but it can be done George> in DSLITE the point is that there is a big IPv6 network in the middle. Which DSLITE bypasses. In Mobile networks the big part of the network is the access part, and there is not much to bypass between GW and CGN Kent> There are still cases were you have to traverse an IPv6 core. 8. Security defect: RFC 3344 (and its -bis version) 10 min Charlie can be implemented so as to permit operation which is vulnerable to third-party denial-of-service attacks. draft-perkins-mip4-authreqd-00.txt Charlie> short presentation… Some discussion regarding authenticated failures with Kent, George, Charlie. Henrik> I run into this before. If you permit an unauthenticated failure you are open to DoS attacks. There were a number of cases we could authenticate and in some others not. Kent> I understand the scenario. So if there is an SA then it can authenticate. The only case is when the HA does not have an SA to authenticate the RRP, in which case according to the RFC you cannot really respond. Some SDOs though wanted to respond for informational reason and they have specified ways of doing it. Charlie> That is ok, it is meant to require authentication in RRP when that is possible. Some discussion between Kent, Henrik, Charlie about the possibility of using another, possibly long lived SA, for this. Alper> In WiMax forum there was confusion regarding the use of authenticators in RRP, so it would be good to clarify and align it to other SDOs. Henrik> do we solve this in RFC3344bis or not? Alper> it would be better to resolve it there. Easier for people to see it. Henrik> …to Charlie…Make a proposal and SDOs etc will respond. George> if we put this in RFC3344bis then we should not deal with the alternate SA option Charlie> Well it could be done but I will remove it if it is contentious.