Re: HOMENET working group proposal
Martin Rex wrote: How do you think about P2P applications? NAT-PMP or IGD over UPnP come to mind. P2P applications need seed peers with fixed addresses and ports. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [homegate] HOMENET working group proposal
On 06/30/2011 02:12 AM, Mikael Abrahamsson wrote: My high level comment/question is: the proposed charter seems to stress that IPv6 is the driver behind this potential wg effort... however, I think that this deserves more discussion -- it's not clear to me why/how typical IPv6 home networks would be much different from their IPv4 counterparts. In my mind, I see the possibility of /56 PD enabling different subnets for different kinds of devices with different security and functional needs, and also chaining of L3 devices. This definitely warrants a group to look at that. My point was that, except for the mechanism for PD, I don't see a substantial difference here that would e.g. prevent this from being developed for IPv4 (in addition to IPv6). -- Yes, I know we need to deploy IPv6... but I don't think you can expect people to get rid of their *working* IPv4 devices... (i.e., not sure why any of this functionality should be v6-only) One would hope/expect that the former will be gone with IPv6. However, I don't think the latter will. As a result, even when you could address nodes that belong to the home network, you probably won't be able to get your packets to them, unless those nodes initiated the communication instance. This is exactly why the whole system needs to work, including uPNP like functionality for nodes to talk to the firewall(s). I think this deserves a problem statement that clearly describes what we expect to be able to do (but currently can't), etc. And, if this is meant to be v6-only, state why v4 is excluded -- unless we're happy to have people connect their IPv4-devices, and see that they cannot communicate anymore. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: HOMENET working group proposal
On 06/30/2011 12:56 AM, Masataka Ohta wrote: Fernando Gont wrote: I personally consider this property of end-to-end connectivity as gone. How do you think about P2P applications? I think about applications that would benefit from e2e connectivity, but since it is gone, they have to spend quite a bit of effort to traverse middleboxes such as NATs. -- the network is not dumb anymore. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: HOMENET working group proposal
On 06/30/2011 02:26 AM, Keith Moore wrote: Rather than having another of an endless series of discussions about the merits of NAT or lack thereof, can we just agree that it should not be pre-ordained that this WG should assume NAT as a solution? I was originally arguing, at the very least, in favour of a stateful firewall at the border. Please correct me if I'm wrong, but this is what the IETF has already proposed (output of v6ops) for v6. I don't think you want your home network to be owned as a result of last patch Tuesday set of vulnerabilities... or that you want a brittle printer or fridge possibly impossible to patch) to be DoSed/owned just because it was cool to have it available on the Internet. (nor should we expect them to run a host-based firewall). Many/most networks are there to provide a specific service to their users (not for us to experiment with) -- whether we like it or not. As long as they are able to provide that service, I don't find a compelling reason for them to increase risk through unnecessary increased exposure. (Yes, in those cases in which you *need* increased exposure, you open your network -- i.e., default deny) Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: HOMENET working group proposal
Fernando Gont wrote: I personally consider this property of end-to-end connectivity as gone. How do you think about P2P applications? I think about applications that would benefit from e2e connectivity, but since it is gone, they have to spend quite a bit of effort to traverse middleboxes such as NATs. -- the network is not dumb anymore. As I wrote, with PR-IP such as E2ENAT, the network can be dumb. If several fixed port numbers are blocked, what's wrong if the network is dumb? Anyway, as it is a lot easier for applications to traverse NAT than to support IPv6, you should better say IPv6 has never arrived. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: HOMENET working group proposal
Fernando, First off, I'm switching the reply headers to f...@ietf.org now, deleting the old homegate list from this discussion. Secondly, I would like to explain the motivation behind focusing this work on IPv6. Its not so much about IPv6 being different (though I hope it is in some respects). The reason why I want this working group to focus on IPv6 is that I don't think new IETF work would have much effect on IPv4 home network architecture. Whereas I think we have a good chance of having an effect in the IPv6 case, given that there is not much deployed base yet in home routers, consumer ISPs, etc. Finally, I don't think we need to take a black-and-white approach to discussing the end-to-end model. Obviously we know about the V6OPS simple security work. Of course there are firewalls in IPv6, restricting incoming traffic. That being said, I think the right architecture for IPv6 home networks is that incoming traffic is restricted *by policy* on a per-need basis, not by an addressing design that forever prevents us from allowing specific incoming protocols. This is what we mean by architecture specification from this working group. Practical network design that does the right thing and lets people do what they want -- not a requirement to open your network up for anything. Jari Fernando Gont kirjoitti: Hi, Jari, My high level comment/question is: the proposed charter seems to stress that IPv6 is the driver behind this potential wg effort... however, Ie think that this deserves more discussion -- it's not clear to me why/how typical IPv6 home networks would be much different from their IPv4 counterparts. Bellow you'll find some comments/questions about the proposed charter. They are not an argument against or in favour of the creation of the aforementioned wg, but rather comments and/or requests for clarification... On 06/29/2011 05:47 AM, Jari Arkko wrote: [] o Service providers are deploying IPv6, and support for IPv6 is increasingly available in home gateway devices. While IPv6 resembles IPv4 in many ways, it changes address allocation principles and allows direct IP addressability and routing to devices in the home from the Internet. This is a promising area in IPv6 that has proved challenging in IPv4 with the proliferation of NAT. NAT devices involve two related but different issues: * address translation * an implicit allow only return traffic firewall-like functionality One would hope/expect that the former will be gone with IPv6. However, I don't think the latter will. As a result, even when you could address nodes that belong to the home network, you probably won't be able to get your packets to them, unless those nodes initiated the communication instance. For instance (and of the top of my head), this functionality is even proposed in the simple security requirements that had been produced by v6ops. o End-to-end communication is both an opportunity and a concern as it enables new applications but also exposes nodes in the internal networks to receipt of unwanted traffic from the Internet. Firewalls that restrict incoming connections may be used to prevent exposure, however, this reduces the efficacy of end-to-end connectivity that IPv6 has the potential to restore. I personally consider this property of end-to-end connectivity as gone. -- among other reasons, because it would require a change of mindset. I'm more of the idea that people will replicate the architecture of their IPv4 networks with IPv6, in which end-systems are not reachable from the public Internet. Thanks! ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [homegate] HOMENET working group proposal
Fernando, My point was that, except for the mechanism for PD, I don't see a substantial difference here that would e.g. prevent this from being developed for IPv4 (in addition to IPv6). -- Yes, I know we need to deploy IPv6... but I don't think you can expect people to get rid of their *working* IPv4 devices... (i.e., not sure why any of this functionality should be v6-only) You have to separate IETF specifications and functionality of real-world products. Obviously everyone is going to have IPv4 based home networks for a long time. But their architecture is largely done and cannot be easily affected. Vendors are now looking into adding IPv6 into their home routers and other devices. I want to be able to show them how to do it right. They can, of course, replicate everything exactly as in IPv4. Much of it is right, of course, but on some areas I think we can do better. This is why the working group should focus on IPv6. If the group is successful, IPv4 network design continues to be what it is, but our recommendations for the IPv6 network design are adopted by vendors' home devices. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [homegate] HOMENET working group proposal
Jari, On 06/30/2011 06:38 AM, Jari Arkko wrote: But their architecture is largely done and cannot be easily affected. Vendors are now looking into adding IPv6 into their home routers and other devices. I want to be able to show them how to do it right. They can, of course, replicate everything exactly as in IPv4. Much of it is right, of course, but on some areas I think we can do better. This is why the working group should focus on IPv6. My point is: Will implementation of the produced RFCs lead to home networks in which stuff works for IPv6 differently from how it works for IPv4? e.g., your home network would have multiple subnets (thanks to PD), but a single IPv4 subnet? If our work focuses only on IPv6, I get the impression that we're heading in that direction. If HOMENET is going to improve stuff that we already do with IPv4 (by leveraging IPv6), then that's fine... but not what I read from this discussion and the proposed charter. Thoughts? Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [homegate] HOMENET working group proposal
Fernando, My point is: Will implementation of the produced RFCs lead to home networks in which stuff works for IPv6 differently from how it works for IPv4? That is the plan. And when I say differently, I mean differences such as * prefix delegation * global addresses and firewalls instead of private addresses and NATs * across-subnet communication internally in the home can be routed, not NATted e.g., your home network would have multiple subnets (thanks to PD), but a single IPv4 subnet? But the examples you cite are not differences we are really aiming at. Multiple subnets is something that generally should be avoided where possible, but cannot be completely avoided. It applies to IPv4 and IPv6 in equal manner, e.g., when you have a Guest and Private SSIDs on your wireless. In this case the difference between IPv4 and IPv6 is merely that in one case we NAT to the Internet and between the two networks, in another case we route/firewall. If our work focuses only on IPv6, I get the impression that we're heading in that direction. If HOMENET is going to improve stuff that we already do with IPv4 (by leveraging IPv6), then that's fine... but not what I read from this discussion and the proposed charter. My point is that I don't think we can change the IPv4 situation. We can affect the way IPv6 is used. Maybe we can even make things better in IPv6 than they were in IPv4. So in the end the user experience may improve for people who use IPv6, but it is definitely not our goal to improve IPv4. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Ietf Digest, Vol 37, Issue 103
Dear Peter, The work group is a discussion/e-meeting where issues/topics are raised and deliberated on. The issues has to do the internet and its related issues. Kind regards, Otueneh Sent from my BlackBerry wireless device from MTN -Original Message- From: Amenawon Osa Peter osa.pe...@gmail.com Sender: ietf-boun...@ietf.org Date: Wed, 29 Jun 2011 23:23:20 To: ietf@ietf.org Subject: Re: Ietf Digest, Vol 37, Issue 103 I as a new member is it possible that i be given a clue on what this work group aim is to enable me be able to contribute positively. thank you On 6/29/11, ietf-requ...@ietf.org ietf-requ...@ietf.org wrote: If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/ietf Click the 'Unsubscribe or edit options' button, log in, and set Get MIME or Plain Text Digests? to MIME. You can set this option globally for all the list digests you receive at this point. Send Ietf mailing list submissions to ietf@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/ietf or, via email, send a message with subject or body 'help' to ietf-requ...@ietf.org You can reach the person managing the list at ietf-ow...@ietf.org When replying, please edit your Subject line so it is more specific than Re: Contents of Ietf digest... Today's Topics: 1. HOMENET working group proposal (Jari Arkko) 2. RE: [ftpext] Last Call: draft-ietf-ftpext2-hosts-02.txt (File Transfer Protocol HOST Command for Virtual Hosts) to ProposedStandard (Robert McMurray) -- Message: 1 Date: Wed, 29 Jun 2011 10:47:18 +0200 From: Jari Arkko jari.ar...@piuha.net To: homeg...@ietf.org homeg...@ietf.org, IETF Discussion ietf@ietf.org Cc: W. Mark Townsley towns...@cisco.com Subject: HOMENET working group proposal Message-ID: 4e0ae696.4020...@piuha.net Content-Type: text/plain; charset=windows-1252; format=flowed I would like to announce a new effort around home networking and solicit some feedback. HOMENET is a new working group proposal, a variation of the HOMEGATE/HOMENET theme that we discussed last year, but this time looking at it from a different angle. The old effort was mostly focused about what home gateways should do: forwarding, transport, and DNS proxying issues. The new effort is about home networks themselves, in particular what kind of network architecture and configuration is necessary to support IPv6-based home networks. We view IPv4-based home networks as done at this time (or perhaps as cannot be changed anyway). I have been discussing this effort in the background for the last couple of month with Mark Townsley and others, and more publicly since early June. The proposal has been brought to the IESG, IAB and some directorates for discussion, and we've been going back and forth whether this is ready to become a working group or needs to be run as a BOF in Quebec City. The current plan is that the working group proposal goes to IETF-wide review this week, and if the feedback from the community, IAB, and the IESG is positive, we will create the working group just in time for the IETF. Otherwise, the slot reserved in the agenda for the meeting will be used to run the proposal as a BOF. In any case, I would like to solicit discussion on this topic, and perhaps some early drafts as well. Please comment on the charter at least. Go here to subscribe https://www.ietf.org/mailman/listinfo/fun and below you can find the most recent charter proposal. Please join the list and the discussion. Note that the new proposal was called FUN at the time that we created the list. It has now been renamed back to HOMENET to be more descriptive. The list will be renamed soon as well (current subscribers will stay). Note also that I'm sending this to the old homegate list, to inform people who were interested in that. I'd like the discussion to happen on the f...@ietf.org list, however. Jari Home Networks (homenet) --- Current Status: Proposed Last Edit: Wednesday, June 29th, 2011 Chairs: TBD Internet Area Directors: Ralph Droms rdroms.i...@gmail.com Jari Arkko jari.ar...@piuha.net Internet Area Advisor: Jari Arkko jari.ar...@piuha.net Routing Area Technical Advisor: TBD Security Area Technical Advisor: TBD Mailing Lists: General Discussion: f...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/fun Archive: http://www.ietf.org/mail-archive/web/fun Description of Working Group: This working group focuses on the evolving networking technology within and among relatively small ?residential home? networks. For example, an obvious trend in home networking is the
Re: [homegate] HOMENET working group proposal
Hi, Mark (and Jari), Thanks so much for your clarification! All my questions/comments have been addressed. Thanks, Fernando On 06/30/2011 06:57 AM, Mark Townsley wrote: I think the consensus we had in the past BoFs and discussion in and around this topic can be summed up as stating that homenet deliverables will: - coexist with (existing) IPv4 protocols, devices, applications, etc. - operate in a (future) IPv6-only home network in the absence of IPv4 - be IP-agnostic whenever possible In other words, anything we do for the IPv6 homenet cannot actively break what's already running on IPv4. Also, trying to define what the IPv4 home network should be has long reached a point of diminishing returns given the effort in doing so coupled with our ability to significantly affect what's already deployed. There's still hope we can help direct IPv6, as such that is homenet's primary focus. However, when we can define something that is needed for IPv6 in a way that is also useful for IPv4 without making significant concessions, we should go ahead and do so. - Mark On Jun 30, 2011, at 9:25 AM, Mikael Abrahamsson wrote: On Thu, 30 Jun 2011, Fernando Gont wrote: My point was that, except for the mechanism for PD, I don't see a substantial difference here that would e.g. prevent this from being developed for IPv4 (in addition to IPv6). -- Yes, I know we need to deploy IPv6... but I don't think you can expect people to get rid of their *working* IPv4 devices... (i.e., not sure why any of this functionality should be v6-only) Chaining NAT boxes already work. I also feel that we shouldn't put in a lot of work to develop IPv4 further, that focus should be put on IPv6. I think this deserves a problem statement that clearly describes what we expect to be able to do (but currently can't), etc. And, if this is meant to be v6-only, state why v4 is excluded -- unless we're happy to have people connect their IPv4-devices, and see that they cannot communicate anymore. IPv4 should be excluded because it's a dead end, and we all know it. We're just disagreeing when it's going to die and how. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homegate mailing list homeg...@ietf.org https://www.ietf.org/mailman/listinfo/homegate ___ homegate mailing list homeg...@ietf.org https://www.ietf.org/mailman/listinfo/homegate -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: HOMENET working group proposal
On Jun 30, 2011, at 12:51 AM, Melinda Shore melinda.sh...@gmail.com wrote: On 6/29/11 8:32 PM, Keith Moore wrote: However it does not follow that home networks need NAT or private address space. Those are hacks of the 1990s. They always were shortsighted, and they turned out to be an operational disaster. We can do better. We can and should, but it's pretty clear that if the IETF were good at evangelizing we wouldn't be in this situation in the first place. The focus really needs to be on producing good, secure protocols that work on the networks we've got. ...or the networks we can see coming in the near future. ZigBee Alliance is driving an IPv6-based multi-link architecture through planned deployments of SE2.0 by several utilities. BBF and CableLabs both expect IPv6, end-to-end connectivity Homenet will avoid breaking existing IPv4 deployments in the networks we've got today, but won't spend resources on unnecessary (in some cases impossible) feature parity. - Ralph Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [homegate] HOMENET working group proposal
On Jun 30, 2011, at 5:47 AM, Fernando Gont wrote: Jari, On 06/30/2011 06:38 AM, Jari Arkko wrote: But their architecture is largely done and cannot be easily affected. Vendors are now looking into adding IPv6 into their home routers and other devices. I want to be able to show them how to do it right. They can, of course, replicate everything exactly as in IPv4. Much of it is right, of course, but on some areas I think we can do better. This is why the working group should focus on IPv6. My point is: Will implementation of the produced RFCs lead to home networks in which stuff works for IPv6 differently from how it works for IPv4? hopefully! e.g., your home network would have multiple subnets (thanks to PD), but a single IPv4 subnet? for that specific example, not clear. my impression is that the architecture of home networks should work regardless of whether there's a single subnet or multiple subnets. If our work focuses only on IPv6, I get the impression that we're heading in that direction. nothing says that some results of the work can't also apply to IPv4. but people are far too mired in outdated assumptions today, such as the idea that every network needs a NAT or a firewall that filters based on IP addresses and ports. If HOMENET is going to improve stuff that we already do with IPv4 (by leveraging IPv6), then that's fine... no, that's not fine. that's painting ourselves (and the Internet) into a corner. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [homegate] HOMENET working group proposal
On 06/30/2011 09:21 AM, Keith Moore wrote: If our work focuses only on IPv6, I get the impression that we're heading in that direction. nothing says that some results of the work can't also apply to IPv4. but people are far too mired in outdated assumptions today, such as the idea that every network needs a NAT or a firewall that filters based on IP addresses and ports. I did not even argue about ports or addressing, but rather about who initiated the communication instance. If HOMENET is going to improve stuff that we already do with IPv4 (by leveraging IPv6), then that's fine... no, that's not fine. that's painting ourselves (and the Internet) into a corner. I was mostly referring to not breaking what already works with v4 (i.e., not be a MUST for all devices in a home network to support some v6 feature for the network to work, such that our existing v4-only devices can co-exist in whatever v6 home-network architecture we envision). Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [sidr] TSVDIR review of draft-ietf-karp-design-guide
I am conufsed by this review of the KARP design guidelines document. My first reaction was that I had trouble understanding the general points. However, when I looked at the more detailed explaantion, what I see is The threats document should But this is not a review of the threats document. As a result, when the review then says the document I have no idea what document is meant. In addition to that general comment, I am completely unable to understand the reviewers concern with the use of the term on the wire. I can believe that there is an issue with the way it is used, but have no clue how to begin to address it. Similarly, there is an assertion that it is important for the document to be more clear on what layers are in and out of scope. This is comment seems to be an assertion by the reviewer not grounded in the document. Neither document is not a scope document. The scope is defined by the charter. Discussion of layers where it is not needed is a distraction. If there are specific places where such additions would be helpful, that is a comment we can react to. As a lesser issue, it is not clear that the different ways of delivering multiple content are actually relevant to the design guidleines document. The different routing protocols have their modes of operations. Ones which send distinct messages to distinct peers are different from ones which, as routing protocols sned single messages to broadcast or multicast. As such, it is not at all clear what the reviewer is asking be clarified in this regard. Yours, Joel M. Halpern On 6/30/2011 1:54 AM, Joe Touch wrote: Hi, all, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. The document discusses design issues for protecting routing protocols. The most problematic issue is the term on the wire which is used in various contexts to imply physical, link, network, or transport protocol layers. This needs to be clarified. Transport protection appears to be a potential focus of the design guide, but is inconsistently discussed. In some cases, transport issues are raised (TCP issues for BGP); in other cases, the relevant transport isn't even noted (e.g., RIP over UDP). This should be corrected throughout. It is important for this document to be more clear on what layers were in scope for the design guide, and what guidelines are being given with respect to those layers, even in a general sense. Further information on these issues is provided below. There is additional feedback provided below (other notes) as a suggestion. I hope this feedback will be useful to the authors, and will be glad to provide further assistance either on- or off-list as useful. Joe - please note that some of these comments apply to the draft-ietf-karp-threats-reqs-03 as well; further, there is duplicate text that is not needed in both these docs. FWIW, the threats-reqs doc has many issues as well which are not addressed here. Of the four issues noted in the intro, the last uses the ambiguous term on the wire. This is confusing in both this and the threats doc, and many times both docs us the term 'wire' or 'bits', all of which would typically indicate either the link layer or the physical media or both. There is no rationale for this focus in either document. The threats document should more clearly indicate *why* protection beyond the routing messages (the SIDR work) is needed, and what the expected threats are. These appear to be: - routing protocols often rely on information in the link, transport or network packets - routing protocols often rely on properties of transport connections to infer reachability, e.g., if a TCP connection cannot stay up, then the endpoint's routes should not be considered reachable (if there are other reasons, please clarify) The threats then appear to be: - spoofing link/network addresses - spoofing transport ports - disrupting the TCP connection (where TCP is used) Note that falsification (as noted in the threats doc) is not in this list since it is (IMO) clearly the purvue of the SIDR work. Also out of scope should have been any of the interference issues, unless the *performance* of the TCP connection needs protection. This doc then may need to protect the link or network protocol ID and/or transport protocol from interference. This should be more clearly stated in the threats doc, IMO, and the term on the wire should be avoided. The discussion of multicast should note that multicast can be implemented by
Re: [sidr] TSVDIR review of draft-ietf-karp-design-guide
Hi Joel,
On 6/30/2011 6:13 AM, Joel M. Halpern wrote:
I am conufsed by this review of the KARP design guidelines document.
My first reaction was that I had trouble understanding the general
points. However, when I looked at the more detailed explaantion, what I
see is The threats document should But this is not a review of
the threats document.
As a result, when the review then says the document I have no idea
what document is meant.
From the design guide section 1:
Readers must refer to the [I-D.ietf-karp-threats-reqs] for a
clear definition of the scope, goals, non goals and the
audience for the design work being undertaken in KARP WG.
I did so, and found issues there that caused problems here, which is why
those issues are included.
In addition to that general comment, I am completely unable to
understand the reviewers concern with the use of the term on the wire.
I can believe that there is an issue with the way it is used, but have
no clue how to begin to address it.
There are more than a few who frequently refer to a protocol's packets
on the wire. This is ambiguous and can mean:
- app messages (here, routing PDUs)
- transport messages (e.g., TCP segments)
- network messages (e.g., IP packets)
- link messages (e.g., ethernet segments)
- the physical media (e.g., WIFI)
Protecting each of these results in different kinds of defense. The
document needs to avoid the use of this term as if it were well-defined
in the IETF literature and unambiguous within the IETF community.
Similarly, there is an assertion that it is important for the document
to be more clear on what layers are in and out of scope. This is comment
seems to be an assertion by the reviewer not grounded in the document.
Neither document is not a scope document. The scope is defined by the
charter.
Neither document should expect that readers are familiar with the
charter; relevant context should be summarized in the intro (and is not,
currently).
The KARP charter says:
---
The KARP working group is tasked to work with the routing protocol
working groups in order to improve the communication security of the
packets on the wire used by the routing protocols. This working group is
concerned with message authentication, packet integrity, and denial of
service (DoS) protection. At present, this charter explicitly excludes
confidentiality and non-repudiation concerns.
...
Routing protocols use a range of transport mechanisms and communication
relationships. There are also differences in details among the various
protocols. The working group will attempt to describe the security
relevant characteristics of routings protocols, such as the use or
non-use of TCP, or the frequent use of group communication versus purely
pairwise communication. Using these characteristics, the working group
will then provide suitable common frameworks that can be applied, and
tailored, to improve the communication security of the routing
protocols. In later phases, it is expected that the working group will
investigate the suitably of defining conceptual structures and APIs, so
as to enable further work to be more effective.
---
Again, I note that on the wire is not clear, nor the term packet.
The term transport mechanisms is overloaded, but in the IETF tends to
refer to layer 4; that's not appropriate here, as some important routing
protocols are directly layered over L2 or L3.
Discussion of layers where it is not needed is a distraction.
A design guide to secure routing protocol message exchanges needs to
clearly identify, by example, the expected kinds of protection needed
for the message exchange. This breaks down to two parts:
A- securing the message content
B- securing any information provided by the way in
which the messages are exchanged
1- securing explicit info (e.g., IDs,
if relied upon by the routing protocol)
2- securing implicit info (e.g., connection
status, message ordering or success, etc.,
as used by the routing protocol)
AFAICT, KARP is focused on (B) which is necessarily in the context of
L2, L3, and/or L4 {where SIDR addresses (A)}. That's fine, but a
*design* guide should be more clear about what B means, and what kinds
of things to look out for or address.
If there are specific places where such additions would be helpful, that
is a comment we can react to.
I refer you again to the intro, which states:
... Section 8.2 calls for [t]ightening the
security of the core routing infrastructure. Four main steps
were identified for that tightening:
o More secure mechanisms and practices for operating routers.
This work is being addressed in the OPSEC Working Group.
o Cleaning up the Internet Routing Registry repository [IRR],
and securing both the database and the access, so that it
Re: HOMENET working group proposal
From: Melinda Shore melinda.sh...@gmail.com The focus really needs to be on producing good, secure protocols The majority of intrusions now seem to be exploiting bugs (and in some cases bad configurations) in the end-hosts; protocol security flaws are rarely the problem. This makes sense, as there's a lot more code in the applications (i.e. places for bugs which can be exploited) than there is in the protocol itself. Firewalls do help, and so it's worth spending some time on doing a good job to make them effective while yet being flexible. But let's not kid ourselves that anything we can do will totally solve the problem. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [sidr] TSVDIR review of draft-ietf-karp-design-guide
How much of this would change if the abstract began with:
This document captures the design guidance that the KARP working group
is using at the time of publication for guiding the chartered security
analysis and proposal work that it is doing.
And we put that in the front of the intro as well.
(The abstract needs to be replaced with an actual abstract. I had
thought that could be resolved in parallel with the IETF last call.)
Would that help, or would you have the same concerns?
Yours,
Joel
On 6/30/2011 9:52 AM, Joe Touch wrote:
Hi Joel,
On 6/30/2011 6:13 AM, Joel M. Halpern wrote:
I am conufsed by this review of the KARP design guidelines document.
My first reaction was that I had trouble understanding the general
points. However, when I looked at the more detailed explaantion, what I
see is The threats document should But this is not a review of
the threats document.
As a result, when the review then says the document I have no idea
what document is meant.
From the design guide section 1:
Readers must refer to the [I-D.ietf-karp-threats-reqs] for a
clear definition of the scope, goals, non goals and the
audience for the design work being undertaken in KARP WG.
I did so, and found issues there that caused problems here, which is why
those issues are included.
In addition to that general comment, I am completely unable to
understand the reviewers concern with the use of the term on the wire.
I can believe that there is an issue with the way it is used, but have
no clue how to begin to address it.
There are more than a few who frequently refer to a protocol's packets
on the wire. This is ambiguous and can mean:
- app messages (here, routing PDUs)
- transport messages (e.g., TCP segments)
- network messages (e.g., IP packets)
- link messages (e.g., ethernet segments)
- the physical media (e.g., WIFI)
Protecting each of these results in different kinds of defense. The
document needs to avoid the use of this term as if it were well-defined
in the IETF literature and unambiguous within the IETF community.
Similarly, there is an assertion that it is important for the document
to be more clear on what layers are in and out of scope. This is comment
seems to be an assertion by the reviewer not grounded in the document.
Neither document is not a scope document. The scope is defined by the
charter.
Neither document should expect that readers are familiar with the
charter; relevant context should be summarized in the intro (and is not,
currently).
The KARP charter says:
---
The KARP working group is tasked to work with the routing protocol
working groups in order to improve the communication security of the
packets on the wire used by the routing protocols. This working group is
concerned with message authentication, packet integrity, and denial of
service (DoS) protection. At present, this charter explicitly excludes
confidentiality and non-repudiation concerns.
...
Routing protocols use a range of transport mechanisms and communication
relationships. There are also differences in details among the various
protocols. The working group will attempt to describe the security
relevant characteristics of routings protocols, such as the use or
non-use of TCP, or the frequent use of group communication versus purely
pairwise communication. Using these characteristics, the working group
will then provide suitable common frameworks that can be applied, and
tailored, to improve the communication security of the routing
protocols. In later phases, it is expected that the working group will
investigate the suitably of defining conceptual structures and APIs, so
as to enable further work to be more effective.
---
Again, I note that on the wire is not clear, nor the term packet.
The term transport mechanisms is overloaded, but in the IETF tends to
refer to layer 4; that's not appropriate here, as some important routing
protocols are directly layered over L2 or L3.
Discussion of layers where it is not needed is a distraction.
A design guide to secure routing protocol message exchanges needs to
clearly identify, by example, the expected kinds of protection needed
for the message exchange. This breaks down to two parts:
A- securing the message content
B- securing any information provided by the way in
which the messages are exchanged
1- securing explicit info (e.g., IDs,
if relied upon by the routing protocol)
2- securing implicit info (e.g., connection
status, message ordering or success, etc.,
as used by the routing protocol)
AFAICT, KARP is focused on (B) which is necessarily in the context of
L2, L3, and/or L4 {where SIDR addresses (A)}. That's fine, but a
*design* guide should be more clear about what B means, and what kinds
of things to look out for or address.
If there are specific places where such additions would be helpful, that
is a comment we can react to.
I refer you again to the intro, which states:
... Section 8.2 calls for [t]ightening the
security of the core routing
Re: [sidr] TSVDIR review of draft-ietf-karp-design-guide
Hi, Joel, On 6/30/2011 7:14 AM, Joel M. Halpern wrote: How much of this would change if the abstract began with: This document captures the design guidance that the KARP working group is using at the time of publication for guiding the chartered security analysis and proposal work that it is doing. And we put that in the front of the intro as well. (The abstract needs to be replaced with an actual abstract. I had thought that could be resolved in parallel with the IETF last call.) Would that help, or would you have the same concerns? Regarding the context of what the WG focus and scope is, merely referring to the WG isn't sufficient. The relevant points of scope need to be included or explained. However, this doesn't need to refer to the WG at all. The history of the doc is not relevant on that point, except perhaps in the Acks. For the intro and abstract, a clear statement of scope is needed. Joe On 6/30/2011 9:52 AM, Joe Touch wrote: Hi Joel, On 6/30/2011 6:13 AM, Joel M. Halpern wrote: I am conufsed by this review of the KARP design guidelines document. My first reaction was that I had trouble understanding the general points. However, when I looked at the more detailed explaantion, what I see is The threats document should But this is not a review of the threats document. As a result, when the review then says the document I have no idea what document is meant. From the design guide section 1: Readers must refer to the [I-D.ietf-karp-threats-reqs] for a clear definition of the scope, goals, non goals and the audience for the design work being undertaken in KARP WG. I did so, and found issues there that caused problems here, which is why those issues are included. In addition to that general comment, I am completely unable to understand the reviewers concern with the use of the term on the wire. I can believe that there is an issue with the way it is used, but have no clue how to begin to address it. There are more than a few who frequently refer to a protocol's packets on the wire. This is ambiguous and can mean: - app messages (here, routing PDUs) - transport messages (e.g., TCP segments) - network messages (e.g., IP packets) - link messages (e.g., ethernet segments) - the physical media (e.g., WIFI) Protecting each of these results in different kinds of defense. The document needs to avoid the use of this term as if it were well-defined in the IETF literature and unambiguous within the IETF community. Similarly, there is an assertion that it is important for the document to be more clear on what layers are in and out of scope. This is comment seems to be an assertion by the reviewer not grounded in the document. Neither document is not a scope document. The scope is defined by the charter. Neither document should expect that readers are familiar with the charter; relevant context should be summarized in the intro (and is not, currently). The KARP charter says: --- The KARP working group is tasked to work with the routing protocol working groups in order to improve the communication security of the packets on the wire used by the routing protocols. This working group is concerned with message authentication, packet integrity, and denial of service (DoS) protection. At present, this charter explicitly excludes confidentiality and non-repudiation concerns. ... Routing protocols use a range of transport mechanisms and communication relationships. There are also differences in details among the various protocols. The working group will attempt to describe the security relevant characteristics of routings protocols, such as the use or non-use of TCP, or the frequent use of group communication versus purely pairwise communication. Using these characteristics, the working group will then provide suitable common frameworks that can be applied, and tailored, to improve the communication security of the routing protocols. In later phases, it is expected that the working group will investigate the suitably of defining conceptual structures and APIs, so as to enable further work to be more effective. --- Again, I note that on the wire is not clear, nor the term packet. The term transport mechanisms is overloaded, but in the IETF tends to refer to layer 4; that's not appropriate here, as some important routing protocols are directly layered over L2 or L3. Discussion of layers where it is not needed is a distraction. A design guide to secure routing protocol message exchanges needs to clearly identify, by example, the expected kinds of protection needed for the message exchange. This breaks down to two parts: A- securing the message content B- securing any information provided by the way in which the messages are exchanged 1- securing explicit info (e.g., IDs, if relied upon by the routing protocol) 2- securing implicit info (e.g., connection status, message ordering or success, etc., as used by the routing protocol) AFAICT, KARP is focused on (B) which is necessarily
tsv-dir review of draft-ietf-pim-mtid-08
I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. Note : I also reviewed the WG mailing list discussions for this document. This draft is basically ready for publication, but has some issues that in my opinion should be fixed before publication. There are, however, some issues that I think that should be addressed, either in a follow-on document, or a revision of this document. draft-ietf-pim-mtid introduces a new type of PIM Join Attribute [RFC5384], the MT-ID Join Attribute, that extends PIM signaling to cover multiple topologies and to enable the identification of which topology should be used when constructing a particular multicast distribution tree. Multiple topologies have been used for some time in unicast (they are supported by IS-IS and OSPF), and also in multicast. The most common multicast requirement for multiple topologies is for video transport, where important or expensive video streams (say, of sporting events) are protected from disruption by multiple transport on completely different network paths. In that use, if a network link goes down or becomes congested or otherwise suboptimal, another source of the video data is already present and the display can be seamlessly switched to the other copy of the stream. This use case is alluded to in the document. Another use case for multiple-topologies is to separate out different types of traffic (say, latency sensitive traffic from larger, bulk, flows). This is not alluded to in this document, and it is not clear to what extent this was intended. These multiple topologies may or may not result in the replication of data, and so may not be intended by the author. However, I would say that this could be used to support this, and so it will be. If there is some reason NOT to use this mechanism for this purpose, some description of the reasons why would be in order. This document sets up a numerical variable, the MT-ID Join Attribute, to assign to multicast topologies, to be used to separate different topologies for different paths. This number for a given multicast topology need not be the same as any unicast multiple topology identifiers, and similarly the multicast topologies and the underlying unicast topologies may be different. This document is sort, straight-forward, and relatively well-written. I had a few non-fatal issues. (I would be glad to suggest some text for any of these issues to the authors if they interested.) Minor Issues : Section 3.2 - As shown earlier, this value is not required to be the same as the MT-ID used by the unicast routing protocols that contribute routes to the topology. In practice, when only one unicast routing protocol (such as OSPF or IS-IS) is used, the PIM MT-ID is RECOMMENDED to be assigned using the same value as the IGP topology identifier. Using the same example presented earlier, if every route in PIM 500 is contributed by OSPF 1000, it is RECOMMENDED to name this RPF topology as PIM 1000 instead of PIM 500. This is for the purpose of reducing management overhead and simplifying troubleshooting. In the actual example, PIM 500 is not the same network topology as OSPF 1000 (it has an extra link, to the source, obtained by MBGP). This is specifically mentioned previously in the text. So, this is NOT the same example as presented earlier and it is NOT clear that this recommendation applies here. If this is left as is, it will certainly confuse some people. I would suggest adding text to clarify this, or creating another example where the unicast and multicast topologies are the same. Section 4.2.3 - There is at most 1 PIM MT-ID attribute encoded. If there are multiple PIM MT-ID Join Attributes included, only the last one is accepted for this particular source. Processing of the rest of the Join message continues. Is this a typo ? s/at most/at least/ would seem to be appropriate. (It says, at most 1, and then describes what do to if there is more than 1.) Otherwise, please explain what is meant. Section 6. The Labels for Section 6.1 and 6.2 are the same. I suspect this is just a typo, and they should be 6.1. PIM-Hello Options 6.2. PIM Join Attribute Types More Substantive Issues : I had two substantive issues with this document. 1.) The range for the topologies. It is highly likely that the users of this capability would want to use multiple topologies differently for different multicast address ranges. For example, use of two topologies is likely to be an expensive customer option, that not all customers
MILE 'side meeting' Monday night July 25th
Hello, This email is to announce that we will be holding a side meeting for a pre-working group to review the proposed charter and some of the work to be completed in the proposed group. The side meeting will take place Monday, July 25th following the Technical Plenary, at 19:30 PM. Thank you, Kathleen Brian Managed Incident Lightweight Exchange (mile) Proposed Working Group Charter Chairs: Kathleen Moriarty kathleen.moria...@emc.commailto:kathleen.moria...@emc.com Brian Trammell tramm...@tik.ee.ethz.chmailto:tramm...@tik.ee.ethz.ch Security Area Directors: Stephen Farrell stephen.farr...@cs.tcd.iemailto:stephen.farr...@cs.tcd.ie Sean Turner turn...@ieca.commailto:turn...@ieca.com Security Area Advisor: Sean Turner turn...@ieca.commailto:turn...@ieca.com Mailing Lists: General Discussion: m...@ietf.orgmailto:m...@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/mile Archive:http://www.ietf.org/mail-archive/web/mile Description of Working Group: The Managed Incident Lightweight Exchange (MILE) pre-working group will develop standards and extensions for the purpose of improving incident information sharing and handling capabilities based on the work developed in the IETF Extended INCident Handling (INCH) working group. The Incident Object Description Exchange Format (IODEF) in RFC5070 and Real-time Inter-network Defense (RID) in RFC6045 were developed in the INCH working group by international Computer Security Incident Response Teams (CSIRTs) and industry to meet the needs of a global community interested in sharing, handling, and exchanging incident information. The extensions and guidance created by the MILE working group assists with the daily operations of CSIRTs at an organization, service provider, law enforcement, and at the country level. The application of IODEF and RID to interdomain incident information cooperative exchange and sharing has recently expanded and the need for extensions has become more im portant. Efforts continue to deploy IODEF and RID, as well as to extend them to support specific use cases covering reporting and mitigation of current threats such as anti-phishing extensions. An incident could be a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), a system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack, etc.. When an incident is detected, the response may include simply filing a report, notification to the source of the incident, a request to a third party for resolution/mitigation, or a request to locate the source. IODEF defines a data representation that provides a standard format for sharing information commonly exchanged about computer security incidents. RID enables the secure exchange of incident related information in an IODEF format providing options for security, privacy, and policy setting. MILE leverages collaboration and sharing experiences with the work developed in the INCH working group which includes the data model detailed in the IODEF, existing extensions to the IODEF for Anti-phishing (RFC5901), and RID (RFC6045, RFC6046) for the secure exchange of information. MILE will also leverage the experience gained in using IODEF and RID in operational contexts. Related work, drafted outside of INCH will also be reviewed and includes RFC5941, Sharing Transaction Fraud Data. The MILE working group provides coordination for these various extension efforts to improve the capabilities for exchanging incident information. MILE has several objectives with the first being a description a subset of IODEF focused on ease of deployment and applicability to current information security data sharing use cases. MILE also describes a generalization of RID for secure exchange of other security-relevant XML formats. MILE produces additional guidance needed for the successful exchange of incident information for new use cases according to policy, security, and privacy requirements. Finally, MILE produces a document template with guidance for defining IODEF extensions to be followed when producing extensions to IODEF as appropriate, for: * labeling incident reports with data protection, data retention, and other policies, regulations, and laws restricting the handling of those reports * reporting on mail service abuse incidents * reporting forensic data generated during incident investigation * reporting indicators of compromise in incident reports * reporting on financial fraud incidents * reporting incidents involving virtualized environments * referencing SCAP enumerations from within incident reports * profiling and reporting on characteristics of malware suspected or confirmed to be involved in an incident * profiling and reporting on characteristics of actors (persons or groups) suspected
Re: HOMENET working group proposal
On 29/06/11Â 23:18Â -0300, Fernando Gont wrote: On 06/29/2011 05:47 AM, Jari Arkko wrote: [] o Service providers are deploying IPv6, and support for IPv6 is increasingly available in home gateway devices. While IPv6 resembles IPv4 in many ways, it changes address allocation principles and allows direct IP addressability and routing to devices in the home from the Internet. This is a promising area in IPv6 that has proved challenging in IPv4 with the proliferation of NAT. NAT devices involve two related but different issues: * address translation * an implicit allow only return traffic firewall-like functionality I'll add a 3rd component, which is application protocol mangling. What's given NAT a particularly bad name in recent years are the consistently poor SIP ALG implementations in many home routers, along with IPSEC ALGs, and other ALGs that attempt to fix the problem in the wrong way. End-to-end communication might be better approached as the desire to default to a configuration in which ALGs are no longer necessary, and then address firewalling separately, which could just as well default to a no inbound connection policy. o End-to-end communication is both an opportunity and a concern as it enables new applications but also exposes nodes in the internal networks to receipt of unwanted traffic from the Internet. Firewalls that restrict incoming connections may be used to prevent exposure, however, this reduces the efficacy of end-to-end connectivity that IPv6 has the potential to restore. I personally consider this property of end-to-end connectivity as gone. -- among other reasons, because it would require a change of mindset. I'm more of the idea that people will replicate the architecture of their IPv4 networks with IPv6, in which end-systems are not reachable from the public Internet. Home networks are bound to grow complex quite quickly. There's certainly value in using a model that residential users are familiar with, but it should be balanced by the inevitable need to address complexity that will outgrow the ability of many users to manage. A typically complex home network in the near future might be: alarm systems, utility and environmental monitoring, lifeline SIP service (911), Super Bowl broadcasts, etc., all connected via one home gateway device, which may have several outsourced/managed devices installed behind it. Having a simpler demarcation-like gateway device, which defers a lot of that complexity to other components in the network (such as end-to-end security), should go a long way in providing a sustainable model. -- Dan White ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [homegate] HOMENET working group proposal
On Wed, 29 Jun 2011, Fernando Gont wrote: My high level comment/question is: the proposed charter seems to stress that IPv6 is the driver behind this potential wg effort... however, I think that this deserves more discussion -- it's not clear to me why/how typical IPv6 home networks would be much different from their IPv4 counterparts. In my mind, I see the possibility of /56 PD enabling different subnets for different kinds of devices with different security and functional needs, and also chaining of L3 devices. This definitely warrants a group to look at that. A more routed home instead of pure L2 one. One would hope/expect that the former will be gone with IPv6. However, I don't think the latter will. As a result, even when you could address nodes that belong to the home network, you probably won't be able to get your packets to them, unless those nodes initiated the communication instance. This is exactly why the whole system needs to work, including uPNP like functionality for nodes to talk to the firewall(s). I personally consider this property of end-to-end connectivity as gone. -- among other reasons, because it would require a change of mindset. I'm more of the idea that people will replicate the architecture of their IPv4 networks with IPv6, in which end-systems are not reachable from the public Internet. I think this will also change, but not for all devices from all of the Internet. Still, I believe there is a place for a working group to look at this. I have subscribed already. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [homegate] HOMENET working group proposal
On Thu, 30 Jun 2011, Fernando Gont wrote: My point was that, except for the mechanism for PD, I don't see a substantial difference here that would e.g. prevent this from being developed for IPv4 (in addition to IPv6). -- Yes, I know we need to deploy IPv6... but I don't think you can expect people to get rid of their *working* IPv4 devices... (i.e., not sure why any of this functionality should be v6-only) Chaining NAT boxes already work. I also feel that we shouldn't put in a lot of work to develop IPv4 further, that focus should be put on IPv6. I think this deserves a problem statement that clearly describes what we expect to be able to do (but currently can't), etc. And, if this is meant to be v6-only, state why v4 is excluded -- unless we're happy to have people connect their IPv4-devices, and see that they cannot communicate anymore. IPv4 should be excluded because it's a dead end, and we all know it. We're just disagreeing when it's going to die and how. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [homegate] HOMENET working group proposal
I think the consensus we had in the past BoFs and discussion in and around this topic can be summed up as stating that homenet deliverables will: - coexist with (existing) IPv4 protocols, devices, applications, etc. - operate in a (future) IPv6-only home network in the absence of IPv4 - be IP-agnostic whenever possible In other words, anything we do for the IPv6 homenet cannot actively break what's already running on IPv4. Also, trying to define what the IPv4 home network should be has long reached a point of diminishing returns given the effort in doing so coupled with our ability to significantly affect what's already deployed. There's still hope we can help direct IPv6, as such that is homenet's primary focus. However, when we can define something that is needed for IPv6 in a way that is also useful for IPv4 without making significant concessions, we should go ahead and do so. - Mark On Jun 30, 2011, at 9:25 AM, Mikael Abrahamsson wrote: On Thu, 30 Jun 2011, Fernando Gont wrote: My point was that, except for the mechanism for PD, I don't see a substantial difference here that would e.g. prevent this from being developed for IPv4 (in addition to IPv6). -- Yes, I know we need to deploy IPv6... but I don't think you can expect people to get rid of their *working* IPv4 devices... (i.e., not sure why any of this functionality should be v6-only) Chaining NAT boxes already work. I also feel that we shouldn't put in a lot of work to develop IPv4 further, that focus should be put on IPv6. I think this deserves a problem statement that clearly describes what we expect to be able to do (but currently can't), etc. And, if this is meant to be v6-only, state why v4 is excluded -- unless we're happy to have people connect their IPv4-devices, and see that they cannot communicate anymore. IPv4 should be excluded because it's a dead end, and we all know it. We're just disagreeing when it's going to die and how. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homegate mailing list homeg...@ietf.org https://www.ietf.org/mailman/listinfo/homegate ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] FW: Last Call: draft-ietf-behave-ftp64-10.txt (An FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard
[Please note that this message is going to many mailing lists, please trim as appropriate when responding.] I submitted a new version of the draft which addresses most, if not all comments. The most notable change, which I would like to ask previous reviewers to look at again, is the handling of the AUTH command, which is now made much less prominent as a way to make the ALG transparent (clients should use ALGS for this) so text specifying interaction of multiple ALGs could be removed. The draft: http://tools.ietf.org/html/draft-ietf-behave-ftp64-11 The diff with -10: http://tools.ietf.org/rfcdiff?difftype=--hwdiffurl2=draft-ietf-behave-ftp64-11.txt Thanks everyone for reviewing. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [homegate] HOMENET working group proposal
-Original Message- From: homegate-boun...@ietf.org [mailto:homegate-boun...@ietf.org] On Behalf Of Mikael Abrahamsson Sent: 30. juni 2011 07:12 To: Fernando Gont Cc: homeg...@ietf.org; IETF Discussion Subject: Re: [homegate] HOMENET working group proposal On Wed, 29 Jun 2011, Fernando Gont wrote: This is exactly why the whole system needs to work, including uPNP like functionality for nodes to talk to the firewall(s). UPnP like can indeed be UPnP. The UPnP Forum has defined IPv6 firewall control as a part of UPnP now. http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf Telenor, which I work for, is going to ask for this as a part of the IPv6 offering from our CPE vendors. -Erik Taraldsen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [homegate] HOMENET working group proposal
Agreed. I would phrase it this way: How to do IPv6 in an IPv4 world. Some points from the Description: o Service providers are deploying IPv6, and support for IPv6 is increasingly available in home gateway devices. This is only *part* of the story. *Users* have lots of IPv4 devices in their home. o service discovery This is already well handled by UPnP/DLNA o managing routing There were several snippets regarding routing/subnets/heterogeneous networking technologies. There is already work proceeding in IEEE P1905.1 to address issues related to multiple network technologies via a MAC/PHY Abstraction Layer. Also there are applications today that expect a single subnet, so new architectures should not preclude existing applications. regards, kiwin On 6/29/2011 11:51 PM, Fernando Gont wrote: On 06/30/2011 02:12 AM, Mikael Abrahamsson wrote: My high level comment/question is: the proposed charter seems to stress that IPv6 is the driver behind this potential wg effort... however, I think that this deserves more discussion -- it's not clear to me why/how typical IPv6 home networks would be much different from their IPv4 counterparts. In my mind, I see the possibility of /56 PD enabling different subnets for different kinds of devices with different security and functional needs, and also chaining of L3 devices. This definitely warrants a group to look at that. My point was that, except for the mechanism for PD, I don't see a substantial difference here that would e.g. prevent this from being developed for IPv4 (in addition to IPv6). -- Yes, I know we need to deploy IPv6... but I don't think you can expect people to get rid of their *working* IPv4 devices... (i.e., not sure why any of this functionality should be v6-only) One would hope/expect that the former will be gone with IPv6. However, I don't think the latter will. As a result, even when you could address nodes that belong to the home network, you probably won't be able to get your packets to them, unless those nodes initiated the communication instance. This is exactly why the whole system needs to work, including uPNP like functionality for nodes to talk to the firewall(s). I think this deserves a problem statement that clearly describes what we expect to be able to do (but currently can't), etc. And, if this is meant to be v6-only, state why v4 is excluded -- unless we're happy to have people connect their IPv4-devices, and see that they cannot communicate anymore. Thanks, -- Stephen [kiwin] Palm Ph.D. E: p...@kiwin.com Senior Technical Director T: +1-949-926-PALM Broadcom Broadband Communications Group F: +1-949-926-7256 Irvine, California W: http://www.kiwin.com Secondary email accounts: stephenp...@alumni.uci.edu p...@broadcom.com s.p...@ieee.org p...@itu.ch sp...@cs.cmu.edu p...@ics.t.u-tokyo.ac.jp ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [homegate] HOMENET working group proposal
Thanks Mark for stating that. It would really be helpful if this type of text is included in the description/charter. The lack of of this information in the recently distributed material caused several immediate allergic reactions... regards, kiwin On 6/30/2011 2:57 AM, Mark Townsley wrote: I think the consensus we had in the past BoFs and discussion in and around this topic can be summed up as stating that homenet deliverables will: - coexist with (existing) IPv4 protocols, devices, applications, etc. - operate in a (future) IPv6-only home network in the absence of IPv4 - be IP-agnostic whenever possible In other words, anything we do for the IPv6 homenet cannot actively break what's already running on IPv4. Also, trying to define what the IPv4 home network should be has long reached a point of diminishing returns given the effort in doing so coupled with our ability to significantly affect what's already deployed. There's still hope we can help direct IPv6, as such that is homenet's primary focus. However, when we can define something that is needed for IPv6 in a way that is also useful for IPv4 without making significant concessions, we should go ahead and do so. - Mark On Jun 30, 2011, at 9:25 AM, Mikael Abrahamsson wrote: On Thu, 30 Jun 2011, Fernando Gont wrote: My point was that, except for the mechanism for PD, I don't see a substantial difference here that would e.g. prevent this from being developed for IPv4 (in addition to IPv6). -- Yes, I know we need to deploy IPv6... but I don't think you can expect people to get rid of their *working* IPv4 devices... (i.e., not sure why any of this functionality should be v6-only) Chaining NAT boxes already work. I also feel that we shouldn't put in a lot of work to develop IPv4 further, that focus should be put on IPv6. I think this deserves a problem statement that clearly describes what we expect to be able to do (but currently can't), etc. And, if this is meant to be v6-only, state why v4 is excluded -- unless we're happy to have people connect their IPv4-devices, and see that they cannot communicate anymore. IPv4 should be excluded because it's a dead end, and we all know it. We're just disagreeing when it's going to die and how. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homegate mailing list homeg...@ietf.org https://www.ietf.org/mailman/listinfo/homegate ___ homegate mailing list homeg...@ietf.org https://www.ietf.org/mailman/listinfo/homegate -- Stephen [kiwin] Palm Ph.D. E: p...@kiwin.com Senior Technical Director T: +1-949-926-PALM Broadcom Broadband Communications Group F: +1-949-926-7256 Irvine, California W: http://www.kiwin.com Secondary email accounts: stephenp...@alumni.uci.edu p...@broadcom.com s.p...@ieee.org p...@itu.ch sp...@cs.cmu.edu p...@ics.t.u-tokyo.ac.jp ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [fun] [homegate] HOMENET working group proposal
Mark, 100% in agreement with this stance. Just to echo what Fernando has already stated, you can't completely ignore IPv4 in the home network especially when you are talking about a multi-segmented network. For example RFC6204 calls for a separate /64 on each LAN interface per the L-2 requirement. In IPv4 these interfaces nearly always operate in bridged mode. Supporting bridged IPv4 and routed IPv6 on the same physical interface could pose a challenge. Overall I like the concept of not breaking core IPv4 functionality while focussing all new functionality to IPv6. Jason On 6/30/11 5:57 AM, Mark Townsley m...@townsley.net wrote: I think the consensus we had in the past BoFs and discussion in and around this topic can be summed up as stating that homenet deliverables will: - coexist with (existing) IPv4 protocols, devices, applications, etc. - operate in a (future) IPv6-only home network in the absence of IPv4 - be IP-agnostic whenever possible In other words, anything we do for the IPv6 homenet cannot actively break what's already running on IPv4. Also, trying to define what the IPv4 home network should be has long reached a point of diminishing returns given the effort in doing so coupled with our ability to significantly affect what's already deployed. There's still hope we can help direct IPv6, as such that is homenet's primary focus. However, when we can define something that is needed for IPv6 in a way that is also useful for IPv4 without making significant concessions, we should go ahead and do so. - Mark On Jun 30, 2011, at 9:25 AM, Mikael Abrahamsson wrote: On Thu, 30 Jun 2011, Fernando Gont wrote: My point was that, except for the mechanism for PD, I don't see a substantial difference here that would e.g. prevent this from being developed for IPv4 (in addition to IPv6). -- Yes, I know we need to deploy IPv6... but I don't think you can expect people to get rid of their *working* IPv4 devices... (i.e., not sure why any of this functionality should be v6-only) Chaining NAT boxes already work. I also feel that we shouldn't put in a lot of work to develop IPv4 further, that focus should be put on IPv6. I think this deserves a problem statement that clearly describes what we expect to be able to do (but currently can't), etc. And, if this is meant to be v6-only, state why v4 is excluded -- unless we're happy to have people connect their IPv4-devices, and see that they cannot communicate anymore. IPv4 should be excluded because it's a dead end, and we all know it. We're just disagreeing when it's going to die and how. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homegate mailing list homeg...@ietf.org https://www.ietf.org/mailman/listinfo/homegate ___ fun mailing list f...@ietf.org https://www.ietf.org/mailman/listinfo/fun This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [fun] [homegate] HOMENET working group proposal
On 6/30/2011 8:06 AM, Weil, Jason wrote: Overall I like the concept of not breaking core IPv4 functionality while focussing all new functionality to IPv6. It is more than just IPv4 functionality... it is all the deployed applications and devices that utilize IPv4 and for whatever reason, cannot be upgraded to IPv6. 8-) regards, kiwin On 6/30/11 5:57 AM, Mark Townsleym...@townsley.net wrote: I think the consensus we had in the past BoFs and discussion in and around this topic can be summed up as stating that homenet deliverables will: - coexist with (existing) IPv4 protocols, devices, applications, etc. - operate in a (future) IPv6-only home network in the absence of IPv4 - be IP-agnostic whenever possible In other words, anything we do for the IPv6 homenet cannot actively break what's already running on IPv4. Also, trying to define what the IPv4 home network should be has long reached a point of diminishing returns given the effort in doing so coupled with our ability to significantly affect what's already deployed. There's still hope we can help direct IPv6, as such that is homenet's primary focus. However, when we can define something that is needed for IPv6 in a way that is also useful for IPv4 without making significant concessions, we should go ahead and do so. - Mark On Jun 30, 2011, at 9:25 AM, Mikael Abrahamsson wrote: On Thu, 30 Jun 2011, Fernando Gont wrote: My point was that, except for the mechanism for PD, I don't see a substantial difference here that would e.g. prevent this from being developed for IPv4 (in addition to IPv6). -- Yes, I know we need to deploy IPv6... but I don't think you can expect people to get rid of their *working* IPv4 devices... (i.e., not sure why any of this functionality should be v6-only) Chaining NAT boxes already work. I also feel that we shouldn't put in a lot of work to develop IPv4 further, that focus should be put on IPv6. I think this deserves a problem statement that clearly describes what we expect to be able to do (but currently can't), etc. And, if this is meant to be v6-only, state why v4 is excluded -- unless we're happy to have people connect their IPv4-devices, and see that they cannot communicate anymore. IPv4 should be excluded because it's a dead end, and we all know it. We're just disagreeing when it's going to die and how. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homegate mailing list homeg...@ietf.org https://www.ietf.org/mailman/listinfo/homegate ___ fun mailing list f...@ietf.org https://www.ietf.org/mailman/listinfo/fun This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ fun mailing list f...@ietf.org https://www.ietf.org/mailman/listinfo/fun -- Stephen [kiwin] Palm Ph.D. E: p...@kiwin.com Senior Technical Director T: +1-949-926-PALM Broadcom Broadband Communications Group F: +1-949-926-7256 Irvine, California W: http://www.kiwin.com Secondary email accounts: stephenp...@alumni.uci.edu p...@broadcom.com s.p...@ieee.org p...@itu.ch sp...@cs.cmu.edu p...@ics.t.u-tokyo.ac.jp ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [homegate] HOMENET working group proposal
On Jun 30, 2011, at 4:55 PM, Stephen [kiwin] PALM wrote: Thanks Mark for stating that. It would really be helpful if this type of text is included in the description/charter. The lack of of this information in the recently distributed material caused several immediate allergic reactions... I'm happy to include it in the next rev. - Mark regards, kiwin On 6/30/2011 2:57 AM, Mark Townsley wrote: I think the consensus we had in the past BoFs and discussion in and around this topic can be summed up as stating that homenet deliverables will: - coexist with (existing) IPv4 protocols, devices, applications, etc. - operate in a (future) IPv6-only home network in the absence of IPv4 - be IP-agnostic whenever possible In other words, anything we do for the IPv6 homenet cannot actively break what's already running on IPv4. Also, trying to define what the IPv4 home network should be has long reached a point of diminishing returns given the effort in doing so coupled with our ability to significantly affect what's already deployed. There's still hope we can help direct IPv6, as such that is homenet's primary focus. However, when we can define something that is needed for IPv6 in a way that is also useful for IPv4 without making significant concessions, we should go ahead and do so. - Mark On Jun 30, 2011, at 9:25 AM, Mikael Abrahamsson wrote: On Thu, 30 Jun 2011, Fernando Gont wrote: My point was that, except for the mechanism for PD, I don't see a substantial difference here that would e.g. prevent this from being developed for IPv4 (in addition to IPv6). -- Yes, I know we need to deploy IPv6... but I don't think you can expect people to get rid of their *working* IPv4 devices... (i.e., not sure why any of this functionality should be v6-only) Chaining NAT boxes already work. I also feel that we shouldn't put in a lot of work to develop IPv4 further, that focus should be put on IPv6. I think this deserves a problem statement that clearly describes what we expect to be able to do (but currently can't), etc. And, if this is meant to be v6-only, state why v4 is excluded -- unless we're happy to have people connect their IPv4-devices, and see that they cannot communicate anymore. IPv4 should be excluded because it's a dead end, and we all know it. We're just disagreeing when it's going to die and how. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homegate mailing list homeg...@ietf.org https://www.ietf.org/mailman/listinfo/homegate ___ homegate mailing list homeg...@ietf.org https://www.ietf.org/mailman/listinfo/homegate -- Stephen [kiwin] Palm Ph.D. E: p...@kiwin.com Senior Technical Director T: +1-949-926-PALM Broadcom Broadband Communications Group F: +1-949-926-7256 Irvine, California W: http://www.kiwin.com Secondary email accounts: stephenp...@alumni.uci.edu p...@broadcom.com s.p...@ieee.org p...@itu.ch sp...@cs.cmu.edu p...@ics.t.u-tokyo.ac.jp ___ homegate mailing list homeg...@ietf.org https://www.ietf.org/mailman/listinfo/homegate ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [homegate] HOMENET working group proposal
On Jun 30, 2011, at 5:57 AM, Mark Townsley wrote: I think the consensus we had in the past BoFs and discussion in and around this topic can be summed up as stating that homenet deliverables will: - coexist with (existing) IPv4 protocols, devices, applications, etc. - operate in a (future) IPv6-only home network in the absence of IPv4 - be IP-agnostic whenever possible I'd like for this group to relax the wherever possible bit, so as to not preclude solutions where IPv6 can do a better job than IPv4. IPv4 is a dinosaur gasping for its last breaths. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [fun] [homegate] HOMENET working group proposal
On Jun 30, 2011, at 11:59 AM, Fernando Gont wrote: On 06/30/2011 12:46 PM, Keith Moore wrote: I'd like for this group to relax the wherever possible bit, so as to not preclude solutions where IPv6 can do a better job than IPv4. IPv4 is a dinosaur gasping for its last breaths. Just curious: when you expect IPv4 to be gone? (including gone from home and enterprise networks) I think it will be used for email and the web for at least ten years. I think there will be a need to talk to legacy IPv4-only devices for about that long, perhaps a bit longer. But IPv4 is already difficult to use for a great many applications, and it will only get worse with the imposition of LSN. A home network that only supports IPv4, or which makes IPv6 as crippled as IPv4, is not a desirable goal. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: HOMENET working group proposal
Keith Moore wrote: Perimeter security of some kind is probably appropriate. Not just appropriate, it is an indispensible prerequisite. That doesn't mean that it has to look like firewalls do today. Not necessarily. But any sensible security requirements and primarily the requirement of the smallest possible attack surface amount to it. If it has to walk like a duck and quack like a duck, just use a duck instead of trying to retrain a goat. For one thing, users shouldn't have to muck with the details of which ports to allow. _Unless_ they want to make a service accessible to the internet with software produced by folks or companys which prioritize features and merchantability far over security, quality and robustness -- which is to say 99.999% of the available software. And the idea that every application server on a home network needs to negotiate access through some application-specific external server (as is generally the case with NATs today) is also ridiculous. No, it is a simple technical problem that can be solved with a few lines of extra code for those few applications where it acutally matters. Just as democracy is the worst form of government except all the others that have been tried (attributed to Winston Churchill). Home networks should ALWAYS be NATed to the internet, so that it is not possible to provide a simple policy switch to make everything on the home network fully accessible from the internet, because any such switch will inevitably be abused much more often by the bad, poor novices and ignorant than sensibly employed by the needy and security conscious. Black-listing doesn't provide security, it always amounts to obscurity and security theater. Anything else than whitelisting is irresponsible security-wise. And dynamic whitelisting (the motivation behind NAT-PMP) is even better. Privacy is another issue. The current custom here in Germany is that the external IP-Address on your home gateway is dynamically assigned, it changes on every new assignment, i.e. when the DSL connection is reestablished after a carrier loss or cable disconnect, whenever you ask your DSL router for it, and at least once every 24 hours. While this does not provide perfect privacy protection, it is a good start. For many internet usage scenarios, the use of a longterm static IP-Address for home users would be completely irresponsible with respect to data privacy, and would likely make any logging of client IP-Addresses on servers unconditionally illegal in European countries. With respect to privacy, anything besides striclty voluntary, well-informed opt-in and anytime easy opt-out again, is a non-starter. No application, unless it absolutely, positively and unavoidably needs to should use a fixed/static address without the affected folks having provided conscious and clear consent. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: HOMENET working group proposal
On Jun 30, 2011, at 12:14 PM, Martin Rex wrote: Keith Moore wrote: Perimeter security of some kind is probably appropriate. Not just appropriate, it is an indispensible prerequisite. I could take some issue with the indispensable part, because I also think that PCs are dinosaurs. For a sufficiently small home network, there's a point where a firewall could provide very little marginal gain in exchange for the complexity and fragility that come with it. I do think that some sort of perimeter security should be part of a home network architecture, but I'd strongly object to the idea that hosts and appliances don't need to be secure because they can expect a firewall to provide their security for them. That doesn't mean that it has to look like firewalls do today. Not necessarily. But any sensible security requirements and primarily the requirement of the smallest possible attack surface amount to it. The mostly commonly kinds of firewalls used today do anything but that. For one thing, users shouldn't have to muck with the details of which ports to allow. _Unless_ they want to make a service accessible to the internet with software produced by folks or companys which prioritize features and merchantability far over security, quality and robustness -- which is to say 99.999% of the available software. a. Maybe part of what HOMENET should do is establish security expectations for appliances and applications intended to provide services from such an environment. b. Get out of the habit of thinking that using IP addresses and port numbers as authentication tokens is in any way sane or secure. And the idea that every application server on a home network needs to negotiate access through some application-specific external server (as is generally the case with NATs today) is also ridiculous. No, it is a simple technical problem that can be solved with a few lines of extra code for those few applications where it acutally matters. That's a completely incorrect and ridiculous statement. Home networks should ALWAYS be NATed to the internet, so that it is not possible to provide a simple policy switch to make everything on the home network fully accessible from the internet, because any such switch will inevitably be abused much more often by the bad, poor novices and ignorant than sensibly employed by the needy and security conscious. Another completely ridiculous statement. You're trying to cripple home networks. More generally, you're arguing for the perpetuation of hacks that never did work very well, instead of leaving room for better mechanisms to be developed. Anything else than whitelisting is irresponsible security-wise. And dynamic whitelisting (the motivation behind NAT-PMP) is even better. Whitelisting might be fine. Basing that whitelist on port numbers and IP addresses is insane. And users need better ways to manage the whitelist than typing in arcane information that they don't understand anyway for each service that they want to permit. Privacy is another issue. The current custom here in Germany is that the external IP-Address on your home gateway is dynamically assigned, it changes on every new assignment, i.e. when the DSL connection is reestablished after a carrier loss or cable disconnect, whenever you ask your DSL router for it, and at least once every 24 hours. While this does not provide perfect privacy protection, it is a good start. For many internet usage scenarios, the use of a longterm static IP-Address for home users would be completely irresponsible with respect to data privacy, and would likely make any logging of client IP-Addresses on servers unconditionally illegal in European countries. Dynamically assigned addresses don't provide any privacy protection if there's some service (like Dynamic DNS) that always points to the current address. Again, you're trying to perpetuate brain damage. With respect to privacy, anything besides striclty voluntary, well-informed opt-in and anytime easy opt-out again, is a non-starter. That much I agree with. We disagree about the mechanisms. No application, unless it absolutely, positively and unavoidably needs to should use a fixed/static address without the affected folks having provided conscious and clear consent. Ridiculous. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [homegate] HOMENET working group proposal
On Jun 30, 2011, at 12:33 PM, Mark Townsley wrote: I think the consensus we had in the past BoFs and discussion in and around this topic can be summed up as stating that homenet deliverables will: - coexist with (existing) IPv4 protocols, devices, applications, etc. - operate in a (future) IPv6-only home network in the absence of IPv4 - be IP-agnostic whenever possible I'd like for this group to relax the wherever possible bit, so as to not preclude solutions where IPv6 can do a better job than IPv4. Yes, and I think that IPv6 should naturally do a better job than IPv4 in the cases where it can. My original mail had this restatement of the above, which I think gets closer to what you want: However, when we can define something that is needed for IPv6 in a way that is also useful for IPv4 without making significant concessions, we should go ahead and do so. when the group can define something that is useful in IPv6, it shouldn't matter whether it's also useful for IPv4. please don't constrain home networks to work only within the confines of IPv4 brain damage. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
TSVDIR review of draft-ietf-karp-design-guide
(resending cc'd to the KARP WG rather than SIDR; please respond to this post instead) Hi, all, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. The document discusses design issues for protecting routing protocols. The most problematic issue is the term on the wire which is used in various contexts to imply physical, link, network, or transport protocol layers. This needs to be clarified. Transport protection appears to be a potential focus of the design guide, but is inconsistently discussed. In some cases, transport issues are raised (TCP issues for BGP); in other cases, the relevant transport isn't even noted (e.g., RIP over UDP). This should be corrected throughout. It is important for this document to be more clear on what layers were in scope for the design guide, and what guidelines are being given with respect to those layers, even in a general sense. Further information on these issues is provided below. There is additional feedback provided below (other notes) as a suggestion. I hope this feedback will be useful to the authors, and will be glad to provide further assistance either on- or off-list as useful. Joe - please note that some of these comments apply to the draft-ietf-karp-threats-reqs-03 as well; further, there is duplicate text that is not needed in both these docs. FWIW, the threats-reqs doc has many issues as well which are not addressed here. Of the four issues noted in the intro, the last uses the ambiguous term on the wire. This is confusing in both this and the threats doc, and many times both docs us the term 'wire' or 'bits', all of which would typically indicate either the link layer or the physical media or both. There is no rationale for this focus in either document. The threats document should more clearly indicate *why* protection beyond the routing messages (the SIDR work) is needed, and what the expected threats are. These appear to be: - routing protocols often rely on information in the link, transport or network packets - routing protocols often rely on properties of transport connections to infer reachability, e.g., if a TCP connection cannot stay up, then the endpoint's routes should not be considered reachable (if there are other reasons, please clarify) The threats then appear to be: - spoofing link/network addresses - spoofing transport ports - disrupting the TCP connection (where TCP is used) Note that falsification (as noted in the threats doc) is not in this list since it is (IMO) clearly the purvue of the SIDR work. Also out of scope should have been any of the interference issues, unless the *performance* of the TCP connection needs protection. This doc then may need to protect the link or network protocol ID and/or transport protocol from interference. This should be more clearly stated in the threats doc, IMO, and the term on the wire should be avoided. The discussion of multicast should note that multicast can be implemented by broadcast, true multicast, or serial unicast; these may have different security requirements. The document should more clearly indicate the underlying protocol used as a key property of a routing protocol, especially because (as above) this document appears to focus on guidelines for link, network, and/or transport protocols. E.g., the discussion on OSPF, RIP, and ISIS should more clearly indicate that, e.g., RIP runs over UDP, OSPF runs over IP directly, and IS-IS runs natively over L2. Similar info would be useful for BFD, RSVP, etc. The document is unclear on its overall advice, other than a somewhat general description of do good stuff. E.g., it notes: Not all routing protocol authentication mechanisms provide support for replay attacks, and the design teams should identify such authentication mechanisms and work on them so that this can get fixed. The design teams must look at the protocols that they are working on and see if packets captured from the previous/stale sessions can be replayed. More specific advice would be, e.g.: Not all routing protocol authentication mechanisms provide protection from replay attacks. Such deficiencies should be addressed at that layer, rather than having design teams conclude that such systems thus require lower layer (transport, network, or link) protection from replays. Other notes: Overall, this document would benefit from a revision focused on clarification, where the focus of each section and advice were made more clear. The abstract is excessively detailed and doesn't get to
Re: [homegate] HOMENET working group proposal
On Jun 30, 2011, at 09:36 , Keith Moore wrote: when the group can define something that is useful in IPv6, it shouldn't matter whether it's also useful for IPv4. please don't constrain home networks to work only within the confines of IPv4 brain damage. I suspect what Mr. Townsley and Mr. Arkko are aiming at here is that if FUN can come up with a scheme to make routed home subnetworks work with delegated IPv6 prefixes, then it is probably not too far-fetched that the same scheme could be trivially extended for assigning IPv4 subnets from the RFC 1918 private realm to support dual-stack routed home subnetworks. I'm not expecting home networks to be able to run IPv6-only with the IPv4 Internet mapped to 64:ff9b::/96 through NAT64 for several more years yet. There's a whole crapload of legacy IPv4-only devices in the average home theater system today that nobody wants to cut off from the Internet just yet. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [fun] [homegate] HOMENET working group proposal
Weil, Jason wrote: Overall I like the concept of not breaking core IPv4 functionality while focussing all new functionality to IPv6. Remember that IPv6 became unusably complex by impossible attempts to add new functionality not available with IPv4, which implies that there is no such thing as new functionality of IPv6. E.g. DHCPv4 is better than not-really-stateless configuration by ND. Fernando Gont wrote: Just curious: when you expect IPv4 to be gone? (including gone from home and enterprise networks) It will be long after IPv6 gone (excluding gone from home and enterprise networks, because it is not really there). Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [fun] [homegate] HOMENET working group proposal
In message 5c263f1c-a180-4efc-a44f-3e867c6cf...@apple.com, james woodyatt wri tes: On Jun 30, 2011, at 09:36 , Keith Moore wrote: when the group can define something that is useful in IPv6, it shouldn't ma tter whether it's also useful for IPv4. please don't constrain home networks to work only within the confines of IP v4 brain damage. I suspect what Mr. Townsley and Mr. Arkko are aiming at here is that if FUN c an come up with a scheme to make routed home subnetworks work with delegated IPv6 prefixes, then it is probably not too far-fetched that the same scheme c ould be trivially extended for assigning IPv4 subnets from the RFC 1918 priva te realm to support dual-stack routed home subnetworks. I'm not expecting home networks to be able to run IPv6-only with the IPv4 Int ernet mapped to 64:ff9b::/96 through NAT64 for several more years yet. There 's a whole crapload of legacy IPv4-only devices in the average home theater s ystem today that nobody wants to cut off from the Internet just yet. I'm expecting home nets to be dual stacked for 10+ years after IPv6 is common to the home (2-5) years. If the home gateway has DS-Lite support then that provides a better solution than NAT 444. It also continues to work when the home net goes IPv6 only with the home gateway passing on the DS-Lite parameters from the ISP. Consumer electronics lasts 10+ years. I'm still using my DOCSIS 1.0 modem 8+ years. My router hardware is 13+ years old, the software is newer and is the 6in4 tunnel end point. I've got TV's of similar vintage. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ fun mailing list f...@ietf.org https://www.ietf.org/mailman/listinfo/fun -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: HOMENET working group proposal
Keith Moore wrote: On Jun 30, 2011, at 1:09 AM, Martin Rex wrote: (a bunch of stuff in defense of NAT) Rather than having another of an endless series of discussions about the merits of NAT or lack thereof, can we just agree that it should not be pre-ordained that this WG should assume NAT as a solution? You absolutely want to have fairly fixed addresses within your home network, and you absolutely want to have a short-lived ephemeral IP-Address assigned on your internet side of your home gateway for the purpose of privacy. Otherwise the number of very unpleasant surprises, including stuff like this: http://www.theregister.co.uk/2011/06/30/xbox_swat_police_rait/ is going to become quite popular. And that is really among the mild unpleasant things if every bit that floats in and out your internet gatway has your name stamped on it visibly to everyone. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: HOMENET working group proposal
On Jun 30, 2011, at 18:46 , Martin Rex wrote: And that [false police report incident] is really among the mild unpleasant things... It's also not even remotely relevant. Under the regime where that incident happened, it's not even news anymore when the police do that without any provocation at all. There is nothing about NAT or dynamic subscriber IP assignment that provides any mitigation whatsoever of the risks entailed by living in a regime like that. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: HOMENET working group proposal
On Jun 30, 2011, at 9:46 PM, Martin Rex wrote: Keith Moore wrote: On Jun 30, 2011, at 1:09 AM, Martin Rex wrote: (a bunch of stuff in defense of NAT) Rather than having another of an endless series of discussions about the merits of NAT or lack thereof, can we just agree that it should not be pre-ordained that this WG should assume NAT as a solution? You absolutely want to have fairly fixed addresses within your home network, and you absolutely want to have a short-lived ephemeral IP-Address assigned on your internet side of your home gateway for the purpose of privacy. No, *you* want these things. I do not, and imposing them is not in the interests of users in general. Otherwise the number of very unpleasant surprises, including stuff like this: http://www.theregister.co.uk/2011/06/30/xbox_swat_police_rait/ Nowhere in this article does it say that the user had a static IP address. And as I indicated earlier, even with a dynamic IP address, there are frequently other ways to find a host's IP address. If you force all hosts on a home network to have dynamic IP addresses, you break applications that need stable addresses. If you don't force all hosts on a home network to have dynamic IP addresses, those that don't need stable addresses can still get ephemeral addresses via privacy addresses, DHCP, or other means. You keep arguing for the perpetuation of bad hacks because of accidental properties of those hacks. I'd rather have well-designed mechanisms that are tailor made to suit particular purposes. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Weekly posting summary for ietf@ietf.org
Total of 170 messages in the last 7 days. script run at: Fri Jul 1 00:53:01 EDT 2011 Messages | Bytes| Who +--++--+ 15.88% | 27 | 13.35% | 185247 | mo...@network-heretics.com 1.76% |3 | 15.97% | 221649 | rob...@microsoft.com 5.29% |9 | 3.78% |52401 | ferna...@gont.com.ar 4.12% |7 | 2.92% |40484 | m...@sap.com 2.35% |4 | 3.95% |54801 | to...@isi.edu 3.53% |6 | 2.73% |37874 | s...@resistor.net 3.53% |6 | 2.32% |32150 | joe...@bogus.com 3.53% |6 | 2.04% |28247 | j...@mercury.lcs.mit.edu 2.35% |4 | 2.31% |32121 | evniki...@gmail.com 2.35% |4 | 2.30% |31862 | jari.ar...@piuha.net 2.35% |4 | 2.12% |29459 | john-i...@jck.com 2.94% |5 | 1.52% |21087 | mo...@necom830.hpcl.titech.ac.jp 2.35% |4 | 1.93% |26749 | j...@apple.com 2.35% |4 | 1.89% |26243 | ma...@isc.org 2.35% |4 | 1.74% |24161 | do...@dougbarton.us 1.76% |3 | 1.63% |22668 | p...@broadcom.com 1.18% |2 | 2.15% |29769 | j...@joelhalpern.com 1.76% |3 | 1.38% |19193 | d3e...@gmail.com 1.76% |3 | 1.37% |19036 | j...@jlc.net 1.76% |3 | 1.18% |16442 | paul.hoff...@vpnc.org 1.76% |3 | 1.10% |15256 | julian.resc...@gmx.de 1.18% |2 | 1.23% |16999 | cb.li...@gmail.com 0.59% |1 | 1.72% |23914 | paulfo...@uk.ibm.com 1.18% |2 | 1.08% |14965 | kathleen.moria...@emc.com 1.18% |2 | 0.99% |13707 | m...@townsley.net 1.18% |2 | 0.94% |13020 | rja.li...@gmail.com 0.59% |1 | 1.50% |20759 | otuene...@gmail.com 1.18% |2 | 0.90% |12430 | stephen.farr...@cs.tcd.ie 1.18% |2 | 0.86% |11912 | scott.r...@nist.gov 1.18% |2 | 0.85% |11737 | m...@cloudmark.com 0.59% |1 | 1.42% |19684 | osa.pe...@gmail.com 1.18% |2 | 0.83% |11519 | brian.e.carpen...@gmail.com 1.18% |2 | 0.82% |11352 | barryle...@computer.org 1.18% |2 | 0.76% |10612 | swm...@swm.pp.se 1.18% |2 | 0.75% |10373 | melinda.sh...@gmail.com 0.59% |1 | 1.00% |13821 | ron.even@gmail.com 0.59% |1 | 0.90% |12512 | ebur...@standardstrack.com 0.59% |1 | 0.86% |11990 | marshall.euba...@gmail.com 0.59% |1 | 0.72% | 9943 | even.r...@huawei.com 0.59% |1 | 0.69% | 9534 | nar...@us.ibm.com 0.59% |1 | 0.63% | 8699 | suresh.krish...@ericsson.com 0.59% |1 | 0.60% | 8370 | flu...@cisco.com 0.59% |1 | 0.59% | 8207 | daedu...@btconnect.com 0.59% |1 | 0.56% | 7745 | jason.w...@twcable.com 0.59% |1 | 0.55% | 7681 | ycsi...@gmail.com 0.59% |1 | 0.55% | 7601 | r.e.sonnev...@sonnection.nl 0.59% |1 | 0.49% | 6802 | presn...@qualcomm.com 0.59% |1 | 0.46% | 6451 | dwh...@olp.net 0.59% |1 | 0.46% | 6441 | aiver...@spamresource.com 0.59% |1 | 0.45% | 6268 | t...@ecs.soton.ac.uk 0.59% |1 | 0.44% | 6131 | war...@kumari.net 0.59% |1 | 0.44% | 6098 | i...@cisco.com 0.59% |1 | 0.43% | 6033 | do...@mail-abuse.org 0.59% |1 | 0.43% | 5978 | b...@nostrum.com 0.59% |1 | 0.43% | 5943 | pthub...@cisco.com 0.59% |1 | 0.42% | 5768 | sc...@kitterman.com 0.59% |1 | 0.40% | 5557 | rdroms.i...@gmail.com 0.59% |1 | 0.38% | 5307 | otr...@employees.org 0.59% |1 | 0.37% | 5131 | d...@dcrocker.net 0.59% |1 | 0.37% | 5096 | ra...@qualcomm.com 0.59% |1 | 0.36% | 5033 | petit...@acm.org 0.59% |1 | 0.36% | 5033 | iljit...@muada.com 0.59% |1 | 0.35% | 4844 | a...@anvilwalrusden.com 0.59% |1 | 0.35% | 4810 | huit...@microsoft.com 0.59% |1 | 0.33% | 4646 | erik.tarald...@telenor.com 0.59% |1 | 0.31% | 4289 | j...@jck.com +--++--+ 100.00% | 170 |100.00% | 1387644 | Total ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [fun] [homegate] HOMENET working group proposal
I'd like to second the relaxation of wherever possible, which may lead to a suboptimal solution for several components. JP Vasseur Cisco Fellow Sent from Blackberry - Original Message - From: Mark Townsley [mailto:m...@townsley.net] Sent: Thursday, June 30, 2011 11:33 AM To: Keith Moore mo...@network-heretics.com Cc: IETF Discussion ietf@ietf.org; f...@ietf.org f...@ietf.org; homeg...@ietf.org homeg...@ietf.org Subject: Re: [fun] [homegate] HOMENET working group proposal On Jun 30, 2011, at 5:46 PM, Keith Moore wrote: On Jun 30, 2011, at 5:57 AM, Mark Townsley wrote: I think the consensus we had in the past BoFs and discussion in and around this topic can be summed up as stating that homenet deliverables will: - coexist with (existing) IPv4 protocols, devices, applications, etc. - operate in a (future) IPv6-only home network in the absence of IPv4 - be IP-agnostic whenever possible I'd like for this group to relax the wherever possible bit, so as to not preclude solutions where IPv6 can do a better job than IPv4. Yes, and I think that IPv6 should naturally do a better job than IPv4 in the cases where it can. My original mail had this restatement of the above, which I think gets closer to what you want: However, when we can define something that is needed for IPv6 in a way that is also useful for IPv4 without making significant concessions, we should go ahead and do so. - Mark IPv4 is a dinosaur gasping for its last breaths. Keith ___ homegate mailing list homeg...@ietf.org https://www.ietf.org/mailman/listinfo/homegate ___ fun mailing list f...@ietf.org https://www.ietf.org/mailman/listinfo/fun ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
reminder: Itojun Service Award 2011 nomination
Dear IETFers, Let me remind you for the nomination of the Itojun Service Award. The deadline is July 15. Thanks, Jun Murai === ANNOUNCING: CALL FOR CANDIDATES FOR ITOJUN SERVICE AWARD The Itojun Service Award is presented every year to an individual or a group who has made outstanding contributions in service to the IPv6 community. The deadline for nominations for this year's award is 15 July 2011. The award will be presented at the 82nd meeting of the IETF to be held in November 2011 in Taipei, Taiwan. About the Award The Itojun Service Award was established by the friends of Itojun and administered by the Internet Society (ISOC), recognises and commemorates the extraordinary dedication exercised by Itojun over the course of IPv6 development. The award includes a presentation crystal, a US$3,000 honorarium, and a travel grant. The award is focused on pragmatic technical contributions, especially through development or operation, with the spirit of servicing the Internet. With respect to the spirit, the selection committee seeks contributors to the Internet as a whole; open source developers are a common example of such contributors, although this is not a requirement for expected nominees. While the committee primarily consider practical contributions such as software development or network operation, higher level efforts that help those direct contributions will also be appreciated in this regard. The contribution should be substantial, but could be immature or ongoing; this award aims to encourage the contributor to keep their efforts, rather than just recognizing well established work. Finally, contributions of a group of individuals will be accepted as deployment work is often done by a large project, not just a single outstanding individual. The award is named after Dr. Jun-ichiro Itojun Hagino, who passed away in 2007, aged just 37. Itojun worked as a Senior Researcher at Internet Initiative Japan Inc. (IIJ), was a member of the board of the Widely Integrated Distributed Environment (WIDE) project, and from 1998 to 2006 served on the groundbreaking KAME project in Japan as the IPv6 samurai. He was also a member of the Internet Architecture Board (IAB) from 2003 to 2005. For additional information on the award, please visit http://www.isoc.org/awards/itojun/ Award Nomination Procedure Neither the nominee nor nominator needs to be a member of ISOC. Nominate via email to itojun-award at elists.isoc.org and include the following details: 1. Name and Email address of nominee (in case of a group nominee, names and Email addresses of representative persons of that group) 2. CV/Bio of nominee (in case of a group nominee, a summary of the group's achievements) 3. Statement of recommendation including specific acts, works, contributions, and other criteria that would show the nominee to fit the standard set by Itojun. Please include corroborating references with their name, email address, and telephone number. Conclude with your affiliation, postal address, and telephone number as well as the postal address, telephone and fax number of the nominee. Thank you in advance for your support, Jun Murai Itojun Service Award Selection Committee ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard
The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile' draft-ietf-mpls-tp-cc-cv-rdi-05.txt as a Proposed Standard 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 i...@ietf.org mailing lists by 2011-07-14. 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. Abstract Continuity Check, Proactive Connectivity Verification and Remote Defect Indication functionalities are required for MPLS-TP OAM. Continuity Check monitors the integrity of the continuity of the label switched path for any loss of continuity defect. Connectivity verification monitors the integrity of the routing of the label switched path between sink and source for any connectivity issues. Remote defect indication enables an End Point to report, to its associated End Point, a fault or defect condition that it detects on a pseudo wire, label switched path or Section. This document specifies methods for proactive continuity check, continuity verification, and remote defect indication for MPLS-TP label switched paths, pseudo wires and Sections using Bidirectional Forwarding Detection. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
W3C WebRTC working group meeting: Saturday, July 23 2011
The W3C Web Real-Time Communications working group will meet on Saturday 23 July 2011 afternoon, starting at 2PM, in Quebec City, Canada, co-located with the IETF Meeting. The choice of the date and place is meant to favor synergies between the W3C WebRTC and the IETF RTCWEB groups. IETF attendees, especially those following the RTCWEB WG, are welcome to attend this W3C face-to-face meeting as meeting guests. Attendees need to register before July 15th using the following URL: http://www.w3.org/2002/09/wbs/47318/webrtc-f2f-quebec/ Note that this is a W3C meeting and, thus, it will be held under W3C rules. Regards, Alexa --- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amor...@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com http://www.amsl.com/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6241 on Network Configuration Protocol (NETCONF)
A new Request for Comments is now available in online RFC libraries. RFC 6241 Title: Network Configuration Protocol (NETCONF) Author: R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed. Status: Standards Track Stream: IETF Date: June 2011 Mailbox:rob.e...@gmail.com, m...@tail-f.com, j.schoenwael...@jacobs-university.de, andy.bier...@brocade.com Pages: 113 Characters: 209465 Obsoletes: RFC4741 I-D Tag:draft-ietf-netconf-4741bis-10.txt URL:http://www.rfc-editor.org/rfc/rfc6241.txt The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document is a product of the Network Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6242 on Using the NETCONF Protocol over Secure Shell (SSH)
A new Request for Comments is now available in online RFC libraries. RFC 6242 Title: Using the NETCONF Protocol over Secure Shell (SSH) Author: M. Wasserman Status: Standards Track Stream: IETF Date: June 2011 Mailbox:m...@painless-security.com Pages: 11 Characters: 22704 Obsoletes: RFC4742 I-D Tag:draft-ietf-netconf-rfc4742bis-08.txt URL:http://www.rfc-editor.org/rfc/rfc6242.txt This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK] This document is a product of the Network Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6243 on With-defaults Capability for NETCONF
A new Request for Comments is now available in online RFC libraries. RFC 6243 Title: With-defaults Capability for NETCONF Author: A. Bierman, B. Lengyel Status: Standards Track Stream: IETF Date: June 2011 Mailbox:andy.bier...@brocade.com, balazs.leng...@ericsson.com Pages: 26 Characters: 51568 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-netconf-with-defaults-14.txt URL:http://www.rfc-editor.org/rfc/rfc6243.txt The Network Configuration Protocol (NETCONF) defines ways to read and edit configuration data from a NETCONF server. In some cases, part of this data may not be set by the NETCONF client, but rather a default value known to the server is used instead. In many situations the NETCONF client has a priori knowledge about default data, so the NETCONF server does not need to save it in a NETCONF configuration datastore or send it to the client in a retrieval operation reply. In other situations the NETCONF client will need this data from the server. Not all server implementations treat this default data the same way. This document defines a capability-based extension to the NETCONF protocol that allows the NETCONF client to identify how defaults are processed by the server, and also defines new mechanisms for client control of server processing of default data. [STANDARDS-TRACK] This document is a product of the Network Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6244 on An Architecture for Network Management Using NETCONF and YANG
A new Request for Comments is now available in online RFC libraries. RFC 6244 Title: An Architecture for Network Management Using NETCONF and YANG Author: P. Shafer Status: Informational Stream: IETF Date: June 2011 Mailbox:p...@juniper.net Pages: 30 Characters: 63276 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-netmod-arch-10.txt URL:http://www.rfc-editor.org/rfc/rfc6244.txt The Network Configuration Protocol (NETCONF) gives access to native capabilities of the devices within a network, defining methods for manipulating configuration databases, retrieving operational data, and invoking specific operations. YANG provides the means to define the content carried via NETCONF, both data and operations. Using both technologies, standard modules can be defined to give interoperability and commonality to devices, while still allowing devices to express their unique capabilities. This document describes how NETCONF and YANG help build network management applications that meet the needs of network operators. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the NETCONF Data Modeling Language Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6289 on A Uniform Resource Name (URN) Namespace for CableLabs
A new Request for Comments is now available in online RFC libraries. RFC 6289 Title: A Uniform Resource Name (URN) Namespace for CableLabs Author: E. Cardona, S. Channabasappa, J-F. Mule Status: Informational Stream: IETF Date: June 2011 Mailbox:e.card...@cablelabs.com, suma...@cablelabs.com, jf.m...@cablelabs.com Pages: 7 Characters: 12976 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-cardona-cablelabs-urn-07.txt URL:http://www.rfc-editor.org/rfc/rfc6289.txt This document describes the Namespace Identifier (NID) 'cablelabs' for Uniform Resource Names (URNs) used to identify resources published by Cable Television Laboratories, Inc. (CableLabs). CableLabs specifies and manages resources that utilize this URN identification model. Management activities for these and other resource types are handled by the manager of the CableLabs' Assigned Names and Numbers registry. This document is not an Internet Standards Track specification; it is published for informational purposes. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
BCP 162, RFC 6302 on Logging Recommendations for Internet-Facing Servers
A new Request for Comments is now available in online RFC libraries. BCP 162 RFC 6302 Title: Logging Recommendations for Internet-Facing Servers Author: A. Durand, I. Gashinsky, D. Lee, S. Sheppard Status: Best Current Practice Stream: IETF Date: June 2011 Mailbox:adur...@juniper.net, i...@yahoo-inc.com, d...@fb.com, scott.shepp...@att.com Pages: 5 Characters: 10039 See Also: BCP0162 I-D Tag:draft-ietf-intarea-server-logging-recommendations-04.txt URL:http://www.rfc-editor.org/rfc/rfc6302.txt In the wake of IPv4 exhaustion and deployment of IP address sharing techniques, this document recommends that Internet-facing servers log port number and accurate timestamps in addition to the incoming IP address. This memo documents an Internet Best Current Practice. This document is a product of the Internet Area Working Group Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6318 on Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)
A new Request for Comments is now available in online RFC libraries. RFC 6318 Title: Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME) Author: R. Housley, J. Solinas Status: Informational Stream: IETF Date: June 2011 Mailbox:hous...@vigilsec.com, jaso...@orion.ncsc.mil Pages: 15 Characters: 31488 Obsoletes: RFC5008 I-D Tag:draft-housley-rfc5008bis-01.txt URL:http://www.rfc-editor.org/rfc/rfc6318.txt This document specifies the conventions for using the United States National Security Agency's Suite B algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME) as specified in RFC 5751. This document obsoletes RFC 5008. This document is not an Internet Standards Track specification; it is published for informational purposes. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
