Re: SCTP Mulithoming Communication PATHS Query
On Apr 15, 2010, at 3:30 AM, Sambasiva Rao Manchili wrote: Hallo, I have a query related to SCT Mulithoming communication paths. Host-X: (IPpx IPax): Multihomed Association with Host-Y (IPpy IPay). Host-X SCTP Client is running with SCTP stack provided by Vendor X Host-Y SCTP Server is running with SCTP stack provided by Vendor Y. Notation. IPpx means IP Address of Primary path on Host-X IPax means IP Address of Alternate path on Host-X IPpy means IP Address of Primary path on Host-Y IPpy means IP Address of Primary path on Host-Y Host-X is Communicating as follows :- --- Primary IP to Primary IP Host-X(IPpx)HBEAT--Host-Y(IPpy) Host-X(IPpx)---HBEAT-ACK--Host-Y(IPpy) Alternate IP to Alternate IP Host-X(IPax)HBEAT--Host-Y(IPay) Host-X(IPax)---HBEAT-ACK--Host-Y(IPay) /* * Host-X installed in Customer network. * Customer Network not configured/ not capable to deliver to destination * in the following two paths. I do not know if they have special requirement * to configure their network only primary talks to primary and alternate talks * to alternate, but I see disadvantage in their setup. * Host-X keeps on trying to reach every Destination received in the * INIT_ACK message from Host-Y * */ Primary to Alternate Address Host-X(IPpx)HBEAT--Host-Y(IPay) (DOES N0T REACH IPay) Host-X(IPax)HBEAT--Host-Y(IPpy) (DOES NOT REACH IPpy) Hmm.. Most implementations are satisfied with reaching the destination.. i.e. when you do Primary IP to Primary IP or Alternate IP to Alternate IP this should be all that is needed. In fact at all previous inter-ops the networks were configured as you say here. You CANNOT send a packet from the primary network and have it cross to the secondary. They were always isolated. In fact this is often done to have separate and diverse networks so you have no single point of failure. Placing a router where both networks plugged in to i.e. IPpx-\++/- IPpy \---||---/ /---| R1 |---\ IPax-/++\-- IPay Though it would make it so you could cross between IPpx - IPay and IPax - IPpy.. also introduces a single point of failure. The implementation should really work in this situation above. As I said its how ALL of the SCTP interop's were setup. We did have issues at times with folks setting up their routing tables though. They had to be sure to set in the routes correctly. In fact this is how most implementations I am aware of decide on the source address to put in a packet. They basically follow the router out of the box to determine the interface that the packet will be emitted on and then use the IP address of that interface. That helps so that you won't have ingress filtering cause you grief. As long as you were not using a default route and had two network routes setup to keep IPp traffic on the correct network and vice versus there should be no problem with this scenario... of course it could be one of the implementations is buggy... not all implementations have been at interops.. most but there are a few that have never made it to one.. I would most suspect that you are probably dealing with such a implementation ;-0 Now Host-X was forced to configured Path Max Retransmissions and Max Init Retransmissions to value of 5, while RTO Initial and RTO MAX value is set to 1 second. This results 5 is actually the default value in the RFC.. but it should be settable by socket options :-) 1. to mark the destination endpoint IPay as NETWORK DOWN on Host-X when it exceeds max retranmission in same path(cross) consecutively and 2. then sends INIT from IPpx to IPpy and also IPpx to IPay and as soon as it gets the response from any destination(in customer nework only from IPpy) it is marked as NETWORK UP, 3. but soon or later we receive again NETWORK DOWN and same repeats from step 1. Now the query is, Is it right to tell custome Network to re-configure their network to allow cross communication ? OR Is it MUST to change the Host-X stack to stop communicating Cross i.e., IPpx trying to reach IPay. Well I would think Host-X's stack is rather broken. It really should not be trying to cross communicate IMO. Advantage that I see from Host-X Stack : I also see an advantage with Host-X tranport addresses IPs trying to reach every destination of the peer. When you say every destination.. you are really saying every destination with every source address. Which is not the same as every destination. If you CAN reach IPpx from IPpy .. then IPpx IS reachable. It is often the case that address filtering by an ISP would provide this same behavior. A path in SCTP is NOT the combination of a source and destination address... but ONLY a destination address. Thus if the
Re: The point is to change it: Was: IPv4 depletion makes CNN
Sounds like you'll need to be looking up market, you're not really looking for a soho router at the point where you've got multiple external providers. This device and it's ilk represted the ipv6 functionality availble in a circa mid to late 2009 home router with a retail price of $100-$150. They are pretty good devices. If you're comparing them to a sonic wall tz you're not really comparing the same class of device. by your own admission the later is inadequate so I'm not sure why you'd even bring it up. joel On 06/06/2010 11:39 AM, Ned Freed wrote: Alternate email client usage fail. My apologies. Ned (offlist) On 2010-06-02 07:36, Phillip Hallam-Baker wrote: On Tue, Jun 1, 2010 at 1:19 PM, Ned Freedned.fr...@mrochek.com wrote: As I've stated previously, I believe the main piece that's missing is a SOHO-grade router that has full IPv6 support, 6to4 support, full IPv4/NAT/firewall support, plus a readonably intuitive GUI to administer it all. If such a product exists I continue to be unaware of it. Ned That is my conclusion as well. D-link Dir 825 http://www.dlink.com/products/?pid=DIR-825 real firewall knobs, ipv6 in the gui etc... It think all their high-end home router small business devices are getting features as they get replaced. I have one deployed, screenshot is here: http://www.flickr.com/photos/joelja/4663980030/ This box may have adequate IPv6 support. (Or it may not - several people have raised issues with it's capabilities. Personally, I lack sufficient operational experience with IPv6 to know one way or the other.) But it's severely deficient in terms of IPv4/NAT/firewall capabilities. In particular, while it has decent NATPT support, there is no indication it cannot handle multiple WAN-side IPv4 addresses and/or 1:1 NAT. The firewall is, according to several reviews I've seen, inadequate on the IPV6 side. This puts it in the same category as the Apple Airport line and the Linksys RVS4000 - probably adequate for personal home use. But in no way, shape or form adequate for SOHO use. I was very clear I was talking about the latter, not the former. now would people please stop on this subject, the manufacturers know how to build this stuff. I'm waiting for an existence proof of the truth of this statement. So far I haven't seen one. The closest I've seen so far is the Sonicwall TZ line, but while it's very capable on the IPv4/NAT/firewall side of things, it's IPv6 support appears inadequate - no 6to4, no IPv6 firewall capabilities, etc. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
Alternate email client usage fail. My apologies. Ned (offlist) On 2010-06-02 07:36, Phillip Hallam-Baker wrote: On Tue, Jun 1, 2010 at 1:19 PM, Ned Freedned.fr...@mrochek.com wrote: As I've stated previously, I believe the main piece that's missing is a SOHO-grade router that has full IPv6 support, 6to4 support, full IPv4/NAT/firewall support, plus a readonably intuitive GUI to administer it all. If such a product exists I continue to be unaware of it. Ned That is my conclusion as well. D-link Dir 825 http://www.dlink.com/products/?pid=DIR-825 real firewall knobs, ipv6 in the gui etc... It think all their high-end home router small business devices are getting features as they get replaced. I have one deployed, screenshot is here: http://www.flickr.com/photos/joelja/4663980030/ This box may have adequate IPv6 support. (Or it may not - several people have raised issues with it's capabilities. Personally, I lack sufficient operational experience with IPv6 to know one way or the other.) But it's severely deficient in terms of IPv4/NAT/firewall capabilities. In particular, while it has decent NATPT support, there is no indication it cannot handle multiple WAN-side IPv4 addresses and/or 1:1 NAT. The firewall is, according to several reviews I've seen, inadequate on the IPV6 side. This puts it in the same category as the Apple Airport line and the Linksys RVS4000 - probably adequate for personal home use. But in no way, shape or form adequate for SOHO use. I was very clear I was talking about the latter, not the former. now would people please stop on this subject, the manufacturers know how to build this stuff. I'm waiting for an existence proof of the truth of this statement. So far I haven't seen one. The closest I've seen so far is the Sonicwall TZ line, but while it's very capable on the IPv4/NAT/firewall side of things, it's IPv6 support appears inadequate - no 6to4, no IPv6 firewall capabilities, etc. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
(offlist) On 2010-06-02 07:36, Phillip Hallam-Baker wrote: On Tue, Jun 1, 2010 at 1:19 PM, Ned Freedned.fr...@mrochek.com wrote: As I've stated previously, I believe the main piece that's missing is a SOHO-grade router that has full IPv6 support, 6to4 support, full IPv4/NAT/firewall support, plus a readonably intuitive GUI to administer it all. If such a product exists I continue to be unaware of it. Ned That is my conclusion as well. D-link Dir 825 http://www.dlink.com/products/?pid=DIR-825 real firewall knobs, ipv6 in the gui etc... It think all their high-end home router small business devices are getting features as they get replaced. I have one deployed, screenshot is here: http://www.flickr.com/photos/joelja/4663980030/ This box may have adequate IPv6 support. (Or it may not - several people have raised issues with it's capabilities. Personally, I lack sufficient operational experience with IPv6 to know one way or the other.) But it's severely deficient in terms of IPv4/NAT/firewall capabilities. In particular, while it has decent NATPT support, there is no indication it cannot handle multiple WAN-side IPv4 addresses and/or 1:1 NAT. The firewall is, according to several reviews I've seen, inadequate on the IPV6 side. This puts it in the same category as the Apple Airport line and the Linksys RVS4000 - probably adequate for personal home use. But in no way, shape or form adequate for SOHO use. I was very clear I was talking about the latter, not the former. now would people please stop on this subject, the manufacturers know how to build this stuff. I'm waiting for an existence proof of the truth of this statement. So far I haven't seen one. The closest I've seen so far is the Sonicwall TZ line, but while it's very capable on the IPv4/NAT/firewall side of things, it's IPv6 support appears inadequate - no 6to4, no IPv6 firewall capabilities, etc. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
Sounds like you'll need to be looking up market, you're not really looking for a soho router at the point where you've got multiple external providers. Who said anything about multiple external providers? All I'm talking about is support for a small number of static IPs on a single network interface. Like you'd need to run, say, a couple of small scale servers. This is NOT high end in any way, shape, or form. This device and it's ilk represted the ipv6 functionality availble in a circa mid to late 2009 home router with a retail price of $100-$150. They are pretty good devices. In your opinion, perhaps. But 10 years ago I bought a Sonicwall SOHO router with all of the capabilities - except IPv6 support - I'm talking about here. I think it cost around $250. Is it really too much to ask that, 10 years later, for a comparable device with decent IPv6 support added? If you're comparing them to a sonic wall tz you're not really comparing the same class of device. by your own admission the later is inadequate so I'm not sure why you'd even bring it up. The Sonicwall TZ 100 is available for $289. The D-link unit you are fond of lists for around $160, the Airport Extreme for around $179, the Linksys RVS4000 is the cheapie in the group at around $110. Nevertheless, these are hardly in vastly different price classes. But let's assume, for the moment, that they are - that the extra $100-$200 is a really big deal. So what? My point stands - you have yet to identify anything - even an upscale box - that meets my stated criteria where must be dirt cheap was conspicuous by its absence. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-simple-msrp-sessmatch (Session Matching Update for the Message Session Relay Protocol (MSRP)) to Proposed Standard
This draft is a standards track update to MSRP that mandates that MSRP allow man in the middle attacks. I am strongly opposed to this change and feel that it would be a violation of the spirit of BCP 61 as well as just a bad idea. The security is OK is based on the idea that MITM attacks are already possible so this makes it now worse - see section 5 where it says However, since a man-in-the-middle would in any case be able to modify the domain information in both the SDP and the MSRP messages I don't agree with the assumption that SIP can not protect against MITM attacks and therefore it is OK to mandate support for MITM attacks in MSRP. Who did the security review for this draft? Cullen MSRP co author On Jun 7, 2010, at 8:40 AM, The IESG wrote: The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG (simple) to consider the following document: - 'Session Matching Update for the Message Session Relay Protocol (MSRP) ' draft-ietf-simple-msrp-sessmatch-06.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 ietf@ietf.org mailing lists by 2010-06-21. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-sessmatch-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=19446rfc_flag=0 ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Simple] Last Call: draft-ietf-simple-msrp-acm (An Alternative Connection Model for the Message Session Relay Protocol (MSRP)) to Proposed Standard
I can not see why this draft is needed other than making MITM attacks easier. I request that this not proceed until we can figure out what is going to happen to draft-ietf-simple-msrp-sessmatch then decide if these changes to MSRP are needed or if the existing mechanism are sufficient. On Jun 7, 2010, at 8:39 AM, The IESG wrote: The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG (simple) to consider the following document: - 'An Alternative Connection Model for the Message Session Relay Protocol (MSRP) ' draft-ietf-simple-msrp-acm-09.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 ietf@ietf.org mailing lists by 2010-06-21. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-acm-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18161rfc_flag=0 ___ Simple mailing list sim...@ietf.org https://www.ietf.org/mailman/listinfo/simple Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
--On Sunday, June 06, 2010 14:39 -0700 Joel Jaeggli joe...@bogus.com wrote: Sounds like you'll need to be looking up market, you're not really looking for a soho router at the point where you've got multiple external providers. This device and it's ilk represted the ipv6 functionality availble in a circa mid to late 2009 home router with a retail price of $100-$150. They are pretty good devices. If you're comparing them to a sonic wall tz you're not really comparing the same class of device. by your own admission the later is inadequate so I'm not sure why you'd even bring it up. Joel, Ned has already responded to part of this and I won't repeat, but let me respond to your last comment from my perspective (I assume a similar network with a few servers... but I do have two external providers). Because of the servers, both Ned and I are clearly in the SOHO world, not the client only residential one, as my ISPs remind me by having me write checks every month for business service and multiple static addresses that total around an order of magnitude more than my neighbors are paying for equivalent bandwidth. But, while limited in size and scope, they are (or at least mine) are real networks, not a VPN parasite on an enterprise network somewhere that does the _real_ routing, etc. Devices like the Linksys RV082 and, with a feature set that is a little larger in some areas and smaller in others, the SonicWall TZ and its predecessors, _do_ provide adequate support for networks of that type when they are running IPv4-only. Foe example, the RV082, perhaps because the designers couldn't figure out how to do better in a box of that size and complexity, provides for multiple public external addresses pnly via 1:1 NAT and the SonicWall (at least the earlier one I have) actually understands about public addresses. FWIW, I've got some fairly serious (enterprise class or above, not SOHO class), if old, router iron lying around here. But, even if the vendor were providing good quality IPv6 software and support for it (they aren't), the amount of effort needed to set it up for this type of network would probably be too expensive (which is most of why it got retired years ago). My belief is that we have a serious IPv6 marketing and transition problem until and unless we can get a level of functionality for IPv6 (and, really, for IPv4/IPv6 mixtures of the sorts that Ned's notes imply) at a level of investment roughly equivalent to the costs we are now paying for IPv4 alone. I want to stress that level of investment and terms like expensive are measured in requirements for knowledge, maintenance, configuration fussing, etc., not just hardware. They also include some important issues about support costs on the vendor/ISP side: if an ISP sells a business IPv6 service with certain properties and customers get into trouble, that ISP is itself in trouble if the support requests require third-level or engineering/design staff involvement to understand or resolve. When the hardware costs we are talking about are in the same range as one month's connectivity bills (and all the numbers you and Ned mentioned are, at least for me), they just wash out and disappear compared to aggravation, fussing, and other sysadmin costs. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
a qtn on pmipv6 multi-homing
As per the section 5.4 from rfc 5213: ... ... When a mobile node connects to a Proxy Mobile IPv6 domain through multiple interfaces for simultaneous access, the local mobility anchor MUST allocate a mobility session for each of the attached interfaces. Each mobility session should be managed under a separate Binding Cache entry and with its own lifetime. In this paragraph, Does multiple-interface mean multiple Proxy-care-of-addressess? Would someone throw some light on this? thanks in advance. -Sam 4G RD engineer JDSU ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-simple-msrp-sessmatch (Session Matching Update for the Message Session Relay Protocol (MSRP)) to Proposed Standard
Hi, The intention is not to mandate that MSRP allows man in the middle attacks. The text simply states that it doesn't change what can already be done. If you think that the text gives a wrong picture regarding that, and what is possible what to protect with SIP, I am happy to modify the text. Regards, Christer From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Cullen Jennings [flu...@cisco.com] Sent: Monday, June 07, 2010 7:31 PM To: IETF Mailing List; IESG IESG Subject: Re: Last Call: draft-ietf-simple-msrp-sessmatch (Session Matching Update for the Message Session Relay Protocol (MSRP)) toProposed Standard This draft is a standards track update to MSRP that mandates that MSRP allow man in the middle attacks. I am strongly opposed to this change and feel that it would be a violation of the spirit of BCP 61 as well as just a bad idea. The security is OK is based on the idea that MITM attacks are already possible so this makes it now worse - see section 5 where it says However, since a man-in-the-middle would in any case be able to modify the domain information in both the SDP and the MSRP messages I don't agree with the assumption that SIP can not protect against MITM attacks and therefore it is OK to mandate support for MITM attacks in MSRP. Who did the security review for this draft? Cullen MSRP co author On Jun 7, 2010, at 8:40 AM, The IESG wrote: The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG (simple) to consider the following document: - 'Session Matching Update for the Message Session Relay Protocol (MSRP) ' draft-ietf-simple-msrp-sessmatch-06.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 ietf@ietf.org mailing lists by 2010-06-21. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-sessmatch-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=19446rfc_flag=0 ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ 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: [Simple] Last Call: draft-ietf-simple-msrp-acm (An Alternative Connection Model for the Message Session Relay Protocol (MSRP)) to Proposed Standard
Hi, I am not I understand what this draft has to do with MITM attacks. This is related to which MSRP UA becomes active, by applying COMEDIA. ACM is a separate thing from SESSMATCH - which is the reason the WG decided to split it into two drafts in the first place (originally ACM and SESSMATCH was a single draft). Regards, Christer From: simple-boun...@ietf.org [simple-boun...@ietf.org] On Behalf Of Cullen Jennings [flu...@cisco.com] Sent: Monday, June 07, 2010 7:34 PM To: ietf@ietf.org Cc: sim...@ietf.org; IETF-Announce Subject: Re: [Simple] Last Call: draft-ietf-simple-msrp-acm (An Alternative Connection Model for the Message Session Relay Protocol (MSRP)) to Proposed Standard I can not see why this draft is needed other than making MITM attacks easier. I request that this not proceed until we can figure out what is going to happen to draft-ietf-simple-msrp-sessmatch then decide if these changes to MSRP are needed or if the existing mechanism are sufficient. On Jun 7, 2010, at 8:39 AM, The IESG wrote: The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG (simple) to consider the following document: - 'An Alternative Connection Model for the Message Session Relay Protocol (MSRP) ' draft-ietf-simple-msrp-acm-09.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 ietf@ietf.org mailing lists by 2010-06-21. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-acm-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18161rfc_flag=0 ___ Simple mailing list sim...@ietf.org https://www.ietf.org/mailman/listinfo/simple Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Simple mailing list sim...@ietf.org https://www.ietf.org/mailman/listinfo/simple ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-simple-msrp-acm (An Alternative Connection Model for the Message Session Relay Protocol (MSRP)) to Proposed Standard
The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG (simple) to consider the following document: - 'An Alternative Connection Model for the Message Session Relay Protocol (MSRP) ' draft-ietf-simple-msrp-acm-09.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 2010-06-21. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-acm-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18161rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-simple-msrp-sessmatch (Session Matching Update for the Message Session Relay Protocol (MSRP)) to Proposed Standard
The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG (simple) to consider the following document: - 'Session Matching Update for the Message Session Relay Protocol (MSRP) ' draft-ietf-simple-msrp-sessmatch-06.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 2010-06-21. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-sessmatch-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=19446rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-csi-proxy-send (Secure Proxy ND Support for SEND) to Experimental RFC
The IESG has received a request from the Cga Send maIntenance WG (csi) to consider the following document: - 'Secure Proxy ND Support for SEND ' draft-ietf-csi-proxy-send-04.txt as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2010-06-21. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-csi-proxy-send-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17984rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5845 on Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6
A new Request for Comments is now available in online RFC libraries. RFC 5845 Title: Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6 Author: A. Muhanna, M. Khalil, S. Gundavelli, K. Leung Status: Standards Track Stream: IETF Date: June 2010 Mailbox:ahmad.muha...@ericsson.com, mohamed.kha...@ericsson.com, sgund...@cisco.com, kle...@cisco.com Pages: 25 Characters: 56198 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-netlmm-grekey-option-09.txt URL:http://www.rfc-editor.org/rfc/rfc5845.txt This specification defines a new mobility option for allowing the mobile access gateway and the local mobility anchor to negotiate Generic Routing Encapsulation (GRE) encapsulation mode and exchange the downlink and uplink GRE keys that are used for marking the downlink and uplink traffic that belong to a specific mobility session. In addition, the same mobility option can be used to negotiate the GRE encapsulation mode without exchanging the GRE keys. [STANDARDS TRACK] This document is a product of the Network-based Localized Mobility Management 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 5870 on A Uniform Resource Identifier for Geographic Locations ('geo' URI)
A new Request for Comments is now available in online RFC libraries.
RFC 5870
Title: A Uniform Resource Identifier for
Geographic Locations ('geo' URI)
Author: A. Mayrhofer, C. Spanring
Status: Standards Track
Stream: IETF
Date: June 2010
Mailbox:alexander.mayrho...@ipcom.at,
christ...@spanring.eu
Pages: 23
Characters: 45943
Updates/Obsoletes/SeeAlso: None
I-D Tag:draft-ietf-geopriv-geo-uri-07.txt
URL:http://www.rfc-editor.org/rfc/rfc5870.txt
This document specifies a Uniform Resource Identifier (URI) for
geographic locations using the 'geo' scheme name. A 'geo' URI
identifies a physical location in a two- or three-dimensional
coordinate reference system in a compact, simple, human-readable, and
protocol-independent way. The default coordinate reference system
used is the World Geodetic System 1984 (WGS-84). [STANDARDS TRACK]
This document is a product of the Geographic Location/Privacy 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
Document Action: 'IPFIX Mediation: Problem Statement' to Informational RFC
The IESG has approved the following document: - 'IPFIX Mediation: Problem Statement ' draft-ietf-ipfix-mediators-problem-statement-09.txt as an Informational RFC This document is the product of the IP Flow Information Export Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-problem-statement-09.txt Technical Summary This document specifies an improvement to the PR-SCTP export specified in the IPFIX specifications in RFC5101. This method offers several advantages such as the ability to calculate Data Record losses for PR-SCTP, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, and reduced demands on the Collecting Process. Working Group Summary Flow-based measurement is a popular method for various network monitoring usages. The sharing of flow-based information for monitoring applications having different requirements raises some open issues in terms of measurement system scalability, flow-based measurement flexibility, and export reliability that IPFIX Mediation may help resolve. This document describes some problems related to flow-based measurement that network administrators have been facing, and then describes IPFIX Mediation applicability examples along with the problems. The WG reached consensus for publication. Document Quality The document underwent two WG last call in the IPFIX WG. Personnel Juergen Quittek is shepherding this document. Dan Romascanu is the responsible Area director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol' to Informational RFC
The IESG has approved the following document: - 'Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol ' draft-ietf-radext-status-server-09.txt as an Informational RFC This document is the product of the RADIUS EXTensions Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-status-server-09.txt Technical Summary This document specifies a deployed extenion to RADIUS which enables clients to query the status of a RADIUS server. While the Status-Server Code (12) was defined as experimental in RFC 2865 Section 3, details of the protocol's operation have not been documented until now. Working Group Summary This document has completed RADEXT WG last call, with the primary areas of discussion relating to security and ID field usage. The RADEXT WG elected to recommend this document for publication as an Informational RFC rather than as a standards-Track RFC due to concerns about problems with deployed implementations. The fixes recommended within the document are compatible with existing servers that receive Status-Server packets, but impose new security requirements on clients that send Status-Server packets. Document Quality The document has been reviewed by IETF RADEXT WG members. An expert review has been carried out by Ignacio Goyret. Status-Server has been implemented by multiple vendors, including RADIATOR, FreeRADIUS and Cistron. It is currently in use within EDUROAM, an educational roaming consortium with more than one million users worldwide. As a result, the document reflects operational experience. Personnel Bernard Aboba is the document shepherd for this document. Dan Romascanu is the responsible AD. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Teredo Security Updates' to Proposed Standard
The IESG has approved the following document: - 'Teredo Security Updates ' draft-krishnan-v6ops-teredo-update-10.txt as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-krishnan-v6ops-teredo-update-10.txt Technical Summary This document updates the Teredo specification with regards to the address format, to reduce a minor security vulnerability. Working Group Summary The document has been through the V6OPS discussions and a WGLC, despite not being officially a work item. Document Quality There is an implementation of these changes in Windows Vista. Personnel There is no document shepherd. The responsible Area Director is Jari Arkko. RFC Editor Note Please add This document updates RFC 4380. to the end of the first paragraph in Section 1. Please change s/need to be constructed/MUST be constructed/ in Section 4. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'The application/pkcs10 Media Type' to Informational RFC
The IESG has approved the following document: - 'The application/pkcs10 Media Type ' draft-turner-application-pkcs10-media-type-05.txt as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-turner-application-pkcs10-media-type-05.txt Technical Summary This document allows the IANA registration to point to an active document. The application/pkcs10 media type was originally part of S/MIMEv2 [RFC2311], which was not the product of an IETF WG, along with application/pkcs7-mime and application/pkcs7-signature. When the SMIME WG produced S/MIMEv3 [RFC2633], it did not include the application/pkcs10 text and unfortunately when PKCS#10 was published as RFC 2986 the application/pkcs10 text was not incorporated there . Recently, S/MIMEv3.2 was published and S/MIMEv2 was moved to historic. This means that the IANA registration no longer points to an active document. This document fills that role with text for application/pkcs10 adapted from RFC 2311 and an IANA registration request for application/pkcs10. Working Group Summary This document is not the product of an IETF Working Group. Document Quality The text for formation of the application/pkcs10 media type is adapted from RFC 2311. Only minor changes were made, as can be seen in the diffs between version -00 and -01. Personnel Russ Housley is the document Shepherd. Tim Polk is the responsible Security Area AD. RFC Editor Note In Section 2.1, please make the following substitution: OLD: When the media type application/pkcs10 is used, the body MUST be a CertificationRequest, encoded using the Basic Encoding Rules (BER) [X.690]. Although BER is specified, instead of the more restrictive Distinguished Encoding Rules (DER) [X.690], a typical application will use DER since the CertificationRequest's CertificationRequestInfo has to be DER-encoded in order to be signed. A robust application SHOULD output DER, but allow BER or DER on input. NEW: When the media type application/pkcs10 is used, the body MUST be a CertificationRequest. A robust application SHOULD output DER, but allow BER or DER on input. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'The application/timestamped-data Media Type' to Informational RFC
The IESG has approved the following document: - 'The application/timestamped-data Media Type ' draft-santoni-media-type-tsd-00.txt as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Alexey Melnikov. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-santoni-media-type-tsd-00.txt Technical Summary This document defines a new application/timestamped-data media type used for TimeStampedData envelopes as described in [RFC5544]. Working Group Summary This document is an individual submission. There were no process related issues worth noticing. Document Quality I am not aware of existing implementations. In the case of a Media Type Review, on what date was the request posted? Personnel Alexey Melnikov is the Responsible Area Director. RFC Editor note Please add Updates: 5544 (once approved) to the header of this document. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Conclusion of IP over IEEE 802.16 Networks (16ng)
The IP over IEEE 802.16 Networks (16ng) in the Internet Area has concluded. The IESG contact persons are Ralph Droms and Jari Arkko. The 16ng working group has produced all of its deliverables and completed its charter, and can now be closed. The working group was primarily focused on WiMAX-oriented deployments of IEEE 802.16 and the corresponding IP service. Participants in the WiMAX NWG (network working group) took a very active or leading role in most of the tasks in the 16ng working group, taking advantage of the IETF's broad expertise to produce the 16bg working group deliverables. The working group has produced an analysis and framework for transmitting IP over IEEE 802.16 networks, and specific standards for IP over IPv6 and Ethernet convergence sublayers. The WiMAX NWG specifications point at 16ng's output as normative specifications for both the IPv6 CS and Ethernet CS documents. Jari and I thank all of the IETF participants who have contributed to the various documents produced by the 16ng working group and to the successful completion of the working group's charter. We especially thank Gabriel Montenegro and Soohong Daniel Park who have chaired the working group since its formation. The mailing list will remain open and the list archive will be retained. - Ralph Droms and Jari Arkko, Internet ADs ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
