Re: [netlmm] Last Call: draft-ietf-netlmm-mip-interactions (Interactions betweenPMIPv6 and MIPv6: scenarios and related issues) to Informational RFC
Hello Gerardo, Comments below... On 5/17/2010 8:17 AM, Giaretta, Gerardo wrote: You have one comment on the recommendation in the draft to have separate binding cache entries. This was extensively discussed in the NETLMM WG and also at the IETF Dublin meeting. There was a mailing list discussion after that in September/October 2008 which led to the conclusion in the current version of the draft. You can find more information in the archives at: http://www.ietf.org/mail-archive/web/netlmm/current/msg05533.html Thanks for that link. It was most enlightening, especially in the context of the ensuing discussion. Having reviewed the latter, it seems to me quite likely that the consensus call was (at least) premature. For instance: I object to this. There was absolutely no consensus on this for you guys to decide. There were clarifying questions that people had on what exactly you meant by multi-homing. You didn't respond to any of those emails. and I am sorry, but I thought the discussion was either incomplete or did not steer towards one particular way or the other. For instance, I didn't get a clear answer for my question on why there would be a single BCE when two different interfaces are in use. Could you please clarify? I could go on. And, without naming names, I want to emphasize that the abovementioned objections were made by some real experts. Do you have any links to discussion that _supports_ the consensus call? Furthermore, I still suggest (constructively) that _at the minimum_ a system architect ought to be allowed to have the design freedom to identify the two mobile node identities (and thus the relevant BCEs). What is the downside of enabling new systems to offer such obvious improvements? Or, would it be better to start writing the ...bis document already (just kidding...)? Regards, Charlie P. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-netlmm-mip-interactions (Interactions betweenPMIPv6 and MIPv6: scenarios and related issues) to Informational RFC
Hello folks, Here is a first installment of comments on the abovementioned Internet Draft. The list is not meant to be exhaustive. Moreover, this document presents and identifies all issues pertained to these scenarios and discusses possible means and mechanisms that are recommended to enable them. These two sentences clash, even though it's true a logician can make sense of them. Figure 2 is out of order. The captions to all figures ought to be centered. The following figure illustrates an example following figure -- Figure 3 below of this scenario, where the MN is moving from an access network where PMIPv6 is supported (i.e. MAG functionality is supported) to a network where PMIPv6 is not supported (i.e. MAG functionality is not supported by the AR). This implies that the home link of the MN is actually a PMIPv6 domain. It's true that the figure is drawn this way, but there might be an unwanted inference that such heterogeneous network support _always_ requires PMIP support in the home network. I reckon that was not intended. This scenario is very similar to other hierarchical mobility schemes, including a HMIPv6-MIPv6 scheme. Please make the relevant citations. Note that a race condition where the MN registers the CoA at the HA before the CoA is actually bound to the MAG at the LMA is not possible. Better: Note that there is no race condition whereby the MN registers the CoA at the HA before the CoA is actually bound to the MAG at the LMA. In particular, based on the base specification [RFC3775], Better: In particular, based on [RFC3775], Or, even better: In particular, the base specification [RFC3775] doesn't require the MN to include any identifier, such as the MN-ID [RFC4283], in the Binding Update message other than its Home Address. As described in [RFC4877], the identifier of the MN is known by the Home Agent after the IKEv2 exchange, but this is not used in the MIPv6 signaling, nor as a lookup key for the binding cache. Which naturally leads to the question, Why Not?! This is a problem that really needs to be fixed. Therefore PMIPv6 and MIPv6 will always create two different binding cache entries in the HA/ LMA which implies that the HA and LMA are logically separated. I think this statement is too strong. If I were building such a system, my HA/LMA would probably be aware that the MN-ID was tightly bound to the MN-HoA. So I would almost certainly make sure that there was a single binding cache entry. If you replace will always by might well, and are by might be, then I would agree. Also, it's unfortunate if the typography separates HA from LMA in HA/LMA. * When the mobile node moves from a MIPv6 foreign network to the PMIPv6 home domain, the MAG registers the mobile node at the LMA by sending a Proxy Binding Update. Subsequently, the LMA updates the mobile node's binding cache entry with the MAG address and the MAG emulates the mobile node's home link. Upon detection of the home link, the mobile node will send a de-registration Binding Update to its home agent. It is necessary to make sure that the de-registration of the MIPv6 BU does not change the PMIPv6 binding cache entry just created by the MAG. To me this looks like a major design flaw. It would be better if the mobile node were aware that its registration authority was delegated to the MAG on the home link. Then it would know to avoid this problem. Stated another way, this would be a requirement induced by PMIP on MIPv6-compliant nodes. Asking the obvious, one wonders why an operator of a home network would a) assume that the nodes were MIPv6-unaware, necessitating a PMIP solution, and yet b) assume that the nodes might be MIPv6-aware, so that there is danger of conflict with a PMIP solution. What am I missing? * MIPv6 and PMIPv6 use different mechanisms for handling re- ordering of registration messages and they are sent by different entities. Looks like another design flaw to me. If the HA/LMA is aware of MIPv6 sequence numbers (i.e., actually _is_ a HA), why not require the MAG to _use_ sequence numbers? This would be a trivial matter of inclusion into the PBA. (or binging cache) -- (or binding cache) :-) thanks, I needed that :-) :-) in fact, I need more $$ for my binges :-) * In this mixed scenario, both host-based and network-based security associations are used to update the same binding
Re: Last Call: draft-ietf-netlmm-mip-interactions (Interactions betweenPMIPv6 and MIPv6: scenarios and related issues) to Informational RFC
Hello folks, Here are the rest of my comments on the abovementioned Internet Draft. For this reason, it is recommended that when the MIPv6 home link is implemented as a PMIPv6 domain, the HA/LMA implementation treats the two protocol as independent. Why not first recommend that the HA/LMA implement some platform-specific mechanism for identifying the alternate identifiers (e.g., MN-ID and MN-HoA)? More in details the following principles ... -- In more detail, the following principles ... ... The mobile node needs to bootstrap -- ... The mobile node may need to bootstrap service continuity. Therefore the following steps must be performed by the UE: -- service continuity. Therefore the following steps might be performed by the MN: In the following steps one and two: needs to -- may need to In step three: assign -- may assign Since all these steps must -- If all these steps must that the mobile node establishes -- that the mobile node establish or, better: it is recommended that the mobile node establishes -- the mobile node SHOULD establish along with a little rewording of the next subordinate clause. has Mobile IPv6 stack active -- continues to make use of Mobile IPv6 as if it is attached -- as if it were attached -- BUT: in the scenario under discussion, isn't it? [boot-integrated]: This citation needs to be updated; and, apparently it now has a distinguished author as well as an editor. But, it's been in the RFC editor's queue for TWO YEARS?! That's a new one on me. MN-HoA.For -- MN-HoA. For is this a bug in xml2rfc? For this reason, the mobile node must be configured to propose MN-HoA as the home address in the IKEv2 INTERNAL_IP6_ADDRESS attribute during the IKEv2 exchange with the HA/LMA. I think this qualifies as another requirement placed by PMIP on MIPv6 nodes. Maybe it would be a good idea to make a new section and list these requirements newly placed by PMIP. I'm starting to wonder whether these new mandates might belong in rfc3775bis. When the mobile node hands over -- When the mobile node migrates to basestations perform handovers, not mobile nodes The mobile node may set the R bit defined in NEMO specification a) citation required for NEMO specification b) NEMO specification -- the NEMO specification c) _ouch_! Now we have a new mandate placed by PMIP onto NEMO.! is created irrespective -- may be created regardless I think it is unwise to prohibit implementers from coordinating the binding cache entries of PMIP and MIPv6 if they serve the same mobile node, as I have mentioned earlier In this section it is assumed -- In this section we consider the case where 4.3. Solutions related to scenario B This conflicts with the sentence in section 1: this document presents and identifies all issues pertained to these scenarios and discusses possible means and mechanisms that are recommended to enable them. On 5/3/2010 7:24 AM, The IESG wrote: The IESG has received a request from the Network-based Localized Mobility Management WG (netlmm) to consider the following document: - 'Interactions between PMIPv6 and MIPv6: scenarios and related issues ' draft-ietf-netlmm-mip-interactions-05.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-05-17. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-netlmm-mip-interactions-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17831rfc_flag=0 ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [netlmm] WG Review: Recharter of Network-based Localized Mobility Management (netlmm)
Hello Jari, You make a very clear case. I think this work item should be on the working group charter. It is good that you would otherwise sponsor it. I expect that the discussion of the specification would anyway transpire on the [netlmm] mailing list. Regards, Charlie P. Jari Arkko wrote: (Replies to netlmm WG list and me, please) This working group's new charter is under consideration by the IESG. The new charter has been approved except for one issue. During the comment period we received a request from Julien Laganier to add a work item to the charter, a heartbeat functionality. Please see below for the details. This work item was discussed in the working group as well, but like many other proposals, was not adopted to the final charter that got sent to the IESG. (This was not so much a question of lack of support, but lack of clear choice from the WG to choose a small number of items to work on in addition to the ones already in the new charter. I had asked the WG to not work on everything at the same time...) What's changed now then? Julien writes that this functionality has been adopted for the new LTE network design by 3GPP, is going to be added to the official dependency list, and I know it will be implemented by several parties. Is this a sufficient reason to add this as an official work item to the WG? Note: I have already agreed to AD sponsor this document if it does not end up in the charter. However, there are design decisions that would be better run in the WG, in my opinion. So I would prefer to put this work item to the new charter. Does anyone object to this addition? Please comment before Friday 25th July, 8AM GMT. Jari Julien Laganier wrote: IESG: The 3GPP WG CT4 has added during last meeting in June (CT4#39bis) a dependency for a PMIPv6 path management and failure detection feature such as the one defined in draft-devarapalli-netlmm-pmipv6-heartbeat to its 3GPP TS 29.275 v1.0.0 PMIPv6 based Mobility and Tunneling protocols for which I'm acting as a rapporteur, see: http://list.etsi.org/scripts/wa.exe?A2=ind0807L=3gpp_tsg_ct_wg4T=0P=3346 This feature is crucial to align of PMIPv6-based 3GPP interfaces to the GTP-based interfaces by relying on IETF-developed extensions, rather than 3GPP Vendor Specific extensions, which would benefit neither IETF nor 3GPP, IMHO. I'd thus like to request that an additional deliverable be added to the the charter, and I'm proposing below some strawman text: 8) PMIPv6 path management and failure detection: This will define an extension to the PMIPv6 protocol allowing PMIPv6 peers to verify bidirectional reachability with their peer, detect failure of their peer, and signal their own failure to their peer. Regards, --julien ___ netlmm mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/netlmm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Principles of Spam-abatement
Hello folks, Eric A. Hall wrote: uh, public nudity is (mostly) criminal Too bad! Actually, what is often proscribed is lewd behavior, and nudity is often wrongly considered lewd. Anyway it's awfully difficult to really reconcile nudity with criminal behavior. Regards, Charlie P.
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Hello folks, I was there, and it wasn't so black and white. It's not fair to characterize it so. I suspect that most people there, who voted for the elimination of site-locals, would still be favor of enabling the features that site-locals were intended to offer. Perhaps the majority position could be paraphrased as against site-local, but sorry to see them go. My own vote was for elimination, but I think it will be a mistake if there isn't a way for people to get unique prefixes practically for free. Regards, Charlie P. Keith Moore wrote: This is so typical of the modern IETF -- 102 people were persuaded by handwaving arguments that something bad might happen if a new and useful technique were deployed, and they are being allowed to overwhelm the 20 who were willing to dig in and find and solve any real problems. uh, no. 102 people finally understood just how comprehensively broken SLs are, and managed to finally overwhelm the 20 or so who were still in compete denial about it. Keith
Re: utility of dynamic DNS
Theodore Tso wrote: With Mobile IP, the security model seems to be (in order to avoid triangle routing), that I need to a secure messages to arbitrary machines in the Internet, who then need to somehow magically know that I am the person authorized to redirect traffic for 216175175175 to some other arbitrary point in the Internet (Amazoncom, buycom, yahoocom, ietforg, etc, etc, etc, etc all needs to know that the distinguished name in my X509 certificate is authorized to speak for 216175175175, and can redirect packets sent to that host to far-flung places in the world like to Australia or Finland Yeah, right) Actually, we hope to get it to work without requiring X509 I wonder what someone 30 years ago would have thought about the statement I can get my data to go anywhere in the world All I need is to have the IP address of the destination and some knowledgeable routers that I don't even know about will magically redirect my packets to that address, without me even knowing where it is Sure, that's different than Mobile IP -- I can hear the objection already! But the main difference is that you already believe that IP routing can work I also believe that IP redirection can work, and a lot faster than DNS resolution redirection can work -- or, any other application-oriented approach One is deployable (modulo a few minor bugs in the HOWTO document, which I've been meaning to find time to write up and report, really I have), and I've currently got it set up and working on my laptop today The other, is as near as I can tell, completely and totally hopeless as far as being practical or deployable The approach you favor would require resolution via DNS after every movement That's going to be a disaster for smooth handovers, I reckon Regards, Charlie P
Re: Blue Sheet Etiquette
Hello, Writing your name on the blue sheet is voluntary. Scanning your bar code at the door would be equally voluntary, and moreover could be done at any time during the meeting, coming or going. Plus, duplicates from different days would be more easily eliminated. I'd vote for the bar code method. Regards, Charlie P. John Stracke wrote: The Mormon Tabernacle Choir in Salt Lake City had a pretty good system for checking tickets: wireless bar code scanners. Can't be more expensive than having somebody type in thousands of names, from barely legible writing. I did think of something like that; but then you'd have a queue at the door as people scan their badges. Besides, there's a difference in scale: we do this three times a year, instead of every day (week?). On the plus side, though, the scanner would record the time, and thereby know what meeting you were there for, so you'd eliminate the failure mode where the chair forgets to put the new box in place, and meeting A gets the credit for everybody who went to meeting B. It wouldn't have to be wireless, either; the scanner could be hooked to an old PC which would store the data on disk. /===\ |John Stracke |Principal Engineer | |[EMAIL PROTECTED] |Incentive Systems, Inc.| |http://www.incentivesystems.com|My opinions are my own.| |===| |Cogito ergo Spud. (I think, therefore I yam.) | \===/
Re: I am a strong believer in the democratic process.
Hello Mike, oh i agree! the failure to start from working code is the perniscious failing of most modern IETF WGs I gather you wouldn't have much sympathy for problem statements and requirements documents that are in process within several working groups now. What do you think about, say, progress within the AAA working group, which has already finished those phases? Regards, Charlie P.
Re: The Internet and the Law, the Economist, 13-19 January 2001
Hello, It seems to me that Mobile IPv6 could go a long way towards solving this problem, in conjunction with some sort of automatic home address assignment capability. This topic has been already discussed in connection with the need to support automatic renumbering. Further work could be done by designing a method of assigning such a home address to the IPv6 node based on some other means of identification (e.g., NAI). We already have some specifications about how to do this for IPv4, using AAA and Mobile IPv4. The basic scenario could be as follows: - An application (or, alternatively, some application context) running on some IPv6 node wants to communicate using an address that isn't related to its previous addresses - The node gets a home address from some network that offers such a service - The node uses Mobile IPv6 mechanisms for packet transmission to and from its communications partner -- without having to go through the home network from which the home address was assigned. This is also related to recent ideas about "homeless Mobile IPv6". Crucial to effective operation, however, will be the ability to set up temporary security associations, to avoid unauthorized redirection of traffic flows to and from the newly assigned IPv6 address. Regards, Charlie P. Sean Doran wrote: | Sean, re the IPv6 myth propagated in this article, see | http://playground.sun.com/ipng/specs/ipv6-address-privacy.html Yes, this solves the lower-8-bytes in a notional 8+8, in the sense that it is an identifier of "who", but the draft in question does not seem to deal with the nature of the "where" part of a notional 8+8 address. That is, if some set of bits uniquely identify an always-on residential computer (or some other device fixed in the topology), the randomization of the lower 8 bytes as in 3.2.1 of draft-ietf-ipng-addrconf-privacy-04.txt does not really help, since only one device anywhere will be using the pattern in that host's top 64 bits. Three obvious approaches come to mind: change one's relationship to the global topology using virtual connections (i.e., tunneling), change the entire topology's numbering (i.e., global DHCP-like address leasing even for the biggest ISPs) or use 1:1 NAT at network boundaries, such that a block of N addresses is directly translated into an equal-sized block of N addresses expressed with a different bit pattern. All of these effectively divorce the topological address from the identity, in the sense that getpeername(2) might return two distinct results, viz. where (from the packet header) or who (from some other protocol). All three also break the permanence or globalness or both of an IPv6 address to host mapping. I will say however that I concur with the comment in 4 ibid., "The desires of protecting individual privacy vs. the desire to effectively maintain and debug a network can conflict with each other." It will be interesting to see how the IPv6 architecture will evolve now that these issues are being given more attention, given that some architectures will have greater conflict than others. Sean.
Re: An Internet Draft as reference material
Hello Bob, The intent is that when good useful information and ideas are published in Internet Drafts, they should become Informational RFCs if they merit preservation and referencing. But the problem is that they don't, and there are too many cracks to fall through. - A draft often needs a LOT of work before it could become Informational. This is especially true since the IESG wants to be somewhat careful about what gets out as an RFC. - Sometimes drafts have some BAD ideas mixed in with the GOOD ideas. - Sometimes drafts are _partially_ superseded by later work (note this is almost the same as the last point). - Sometimes drafts are just put out there to stimulate thought/controversy/further work. The authors may have no interest in doing any more work on it after that. Not that I myself would ever do such a thing. - As you point out, people do move on, especially in the IETF. If someone _wants_ to provide proper attribution in order to live up to honorable objectives of intellectual honesty, then it would be convenient for them to be able to cite the original work (i.e., the Internet Draft). Clearly, it is not the IETF's _responsibility_ to provide this archival service. We _may_ wish to accept a _new_ responsibility, or maybe not. I suggest that ISOC consider creation of such a service. Regards, Charlie P. PS. 40 Gbytes $200.
Re: NAT-IPv6
Hello Matt, I probably shouldn't tread into these waters, but... Now, if you have a site which has more hosts than it can get external IPv4 addresses for, then as long as there are considerable numbers of IPv4 hosts a site needs to interoperate with, *deploying IPv6 internally to the site does the site basically no good at all*. I think we've been through all this already and we explored it deeply at the IAB Network Layer Workshop. One of the conclusions is that an IPv6 network NAT'ed to the IPv4 Internet isn't any better than what we have today with IPv4-NAT-IPv4, yet it will allow the given network to move to IPv6 in hopes of someday connecting to other IPv6 networks without using NAT. The last sentence isn't internally self-consistent. NATting from IPv6 to IPv4 creates the potential that you mention, and that is a benefit. SO, it _is_ better. If we get to a model where large new domains use IPv6 addressing with NAT to global IPv4 address space, that would be quite useful. Before too long, services will appear on the IPv6 network that can't get the IPv4 global addresses they need. IPv6 clients will work at least as well as privately-addressed IPv4 clients, so that there is no downside to going IPv6. As this happens more and more, the IPv6 domains will begin to dominate and interconnect efficiently. Since the Internet continues to grow rapidly, today's dominant deployment may well be tomorrow's sad legacy. Or not, depending on who knows what? So if you are NAT'd to the public Internet today, you shouldn't have a problem with converting internally to IPv6. At least from an architectural sense. :) Indeed. And, to re-use an old bit of wisdom: "You're either part of the problem, or part of the solution". Regards, Charlie P.
Re: Internet SYN Flooding, spoofing attacks
Hello Vernon, Well.. as soon as somebody presents us with "the real solution", we'll start implementing. In the meantime, filtering is the best we know how to do. ... I really wish "we" actually knew how to filter. But maybe filtering is putting the cart before the horse. I compare the recent problems with phone harassment. We can install all sorts of doodads, but if we can identify the source of the harassment we can bring charges against them. From that analogy, I claim that the appropriate action is to develop tracing systems that will help to identify a wrongdoer. Here is a possible design. - Create a router feature, able to be remotely activated, to keep track of "suspicious" packets for a few seconds up to maybe a couple dozen seconds. Suspicious packets might be SYNs, or even packets with "incorrect" source addresses. - If a violation is noticed, determine the interface on which a bad packet was received, and send a request to that neighbor along with appropriate credentials that can be checked. - If, on the other hand, a neighbor sends a request for tracing a problematic packet, check the credentials that accompany the request and look at the stored data for that packet. If no stored data exists, send back the bad news, and possibly enable the pattern-matchine function to capture similarly featured packets in case of future requests. - If a neighbor's request refers to a stored packet, figure out what interface the stored packet arrived on. If the packet came from another neighbor, forward the request. Otherwise, look for the malicious source internal to the domain. The basic idea then would be to trace back bad packets that conform to some typically innocent, but occasionally troublesome, profiles. The profiles will become self-evident with experience, and once people know they will be caught by this traceback system they will think twice before spreading their crap around. According to one knowledgeable source, this strategy is undesirable because it would cause routers to maintain more state. But, I claim that we have to maintain state to do any tracing, and I also claim that we need to enable tracing in order to detect and identify wrongdoers. Since the features should be activated by request from trusted neighbors, in the usual case there should not be any significant performance degradation. Clearly, such requests have to be checked for authenticity. So the costs boil down to more memory, more software, some pattern-matching hardware, and maintaining security relationships with your routing partners. I think it's a very worthwhile tradeoff. Much better than mostly ineffective measures that have big negative effects and small positive effects, characteristics of ingress filtering as I understand it. Plus I don't like the attitude of blaming the victim without giving the victim any tools with which to find the perpetrators. Regards, Charlie P.
Re: Internet SYN Flooding, spoofing attacks
Robert Elz wrote: There's no good purpose in sending packets with incorrect source addresses I can think of, and stopping the practice is the basic intent of the filters. Mobile IP would like to send out packets with the mobile node's home address, while it is attached to a network in a foreign domain. The home address is likely to look "incorrect" from the standpoint of such a filter. Plus I don't think the gain is worth the pain. I'd rather see a technology that actually solves the problem instead of swatting at gnats with a sledge hammer. What if routers could preferentially keep track of things like SYN packets and so on for a few seconds, and we had some traceback management software and security associations with our neighbors enough to do some automatic detection? It might cost 2% more for the memory buffers, geez I don't know. Regards, Charlie P.
Re: To address or NAT to address?
With this in mind I hope that the same folks who complained about increased dependencies on DNS by NATs, would be equally vocal in complaining about increased reliance on the DNS by IPv6 (which claimed to be an improvement over NATs). DNS is supposed to be a way to resolve domain names into IP addresses. How else would one get an IP(v6) address from a domain name other than by using DNS? Am I missing something here? Whether to use DNS to resolve a name into a non-address foobar might be debatable. Whether to use DNS to resolve a name into an IP(v6) address is not. Regards, Charlie P.
