clarification needed in address assignment using IKEv2 Configuration Payload
Hi ppl, Recently i have started reading the IKEv2 RFC(5996). I need a clarification on assigning the ip address using ikev2 protocol as below which i couldn't find in the RFC4718: Is it valid to assign 0.0.0.0 IP address in the CFG_REPLY paylaod in IKE_AUTH message to the initiator? I need this information for the scenario where the initiator can obtain the IP address by some other means(say DHCP). But still if the initiator needs a secure channel to communicate with the gateway first, before sending the DHCP request for obtaining IP address. Now when the DHCP server provides the IP-address to the initiator, can the SPD be updated updated at that time(by extracting the ip assigned to the initator from the DHCP message) rather than doing the same during the IKE_AUTH response?(as i am thinking of assigning 0.0.0.0 ip during initial IKE_AUTH response in CFG payload) Because when i looked in to RFC4306 under section 2.19(Requesting an Internal Address on a Remote Network) , it says, Message from responder to initiator: CP(CFG_REPLY)= INTERNAL_ADDRESS(192.0.2.202) INTERNAL_NETMASK(255.255.255.0) INTERNAL_SUBNET( 192.0.2.0/255.255.255.0) TSi = (0, 0-65535,192.0.2.202-192.0.2.202) TSr = (0, 0-65535,192.0.2.0-192.0.2.255) * All returned values will be implementation dependent. There is no mention in RFC something like assigning 0.0.0.0 should be handled as ERROR. So can i safely say assigning 0.0.0.0 ip address is compliant with RFC? Also section 3.15.4. (Address Assignment Failures) says, If the initiator does not receive the IP address(es) required by its policy, it MAY keep the IKE SA up and retry the Configuration payload as separate INFORMATIONAL exchange after suitable timeout Does it mean that the IPSEC-SA cannot be created unless a valid ip is assigned? It is possible to create IPSEC-SA with the traffic-selector alone, rite? why do we need to bother about IP allocation? Assume that there is policy in initiator which says 0.0.0.0 MUST be the ip-address allocated by NAS, then is it valid to send the same in CFG_REPLY payload? Any help is highly appreciated. Thanks, ...Balaji.J ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Buckets of spam coming through IETF lists
On 4/1/2011 9:08 PM, Fred Baker wrote: On Apr 1, 2011, at 10:28 PM, John R. Levine wrote: Some clever spambot seems to have scraped a bunch of addresses out of the archives and is sending spam with multiple addresses on the From: line through IETF and IRTF mailing lists. Surely I'm not the only one who's seeing it. DKIM is directly designed to address this... What do we need to do to put it in play? Unfortunately, DKIM is /not/ design to address this. DKIM is designed to provide a reliable, accurate identifier upon which reputation data can be developed. That's a fundamentally different task from detected invalid From: field contents. ADSP, and add-on to DKIM, is felt by its promoters to be useful for detecting invalid From: fields, but it does not work through mailing lists. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
draft-housley-two-maturity-levels-05
This revision proposes a solution to the issue raised by Brian Carpenter about
documents lingering at Draft Standard. Some people thought it was a problem.
Others thought it did not matter. The proposed solution leaves the matter in
the hands of the IESG.
Russ
Begin forwarded message:
From: IETF I-D Submission Tool idsubmiss...@ietf.org
Date: April 6, 2011 11:22:25 AM EDT
To: hous...@vigilsec.com
Cc: dcroc...@bbiw.net, ebur...@standardstrack.com
Subject: New Version Notification for draft-housley-two-maturity-levels-05
A new version of I-D, draft-housley-two-maturity-levels-05.txt has been
successfully submitted by Russ Housley and posted to the IETF repository.
Filename: draft-housley-two-maturity-levels
Revision: 05
Title: Reducing the Standards Track to Two Maturity Levels
Creation_date: 2011-04-06
WG ID: Independent Submission
Number_of_pages: 7
Abstract:
This document proposes several changes to the Internet Engineering
Task Force (IETF) Standards Process defined in RFC 2026, primarily a
reduction from three IETF standards track maturity levels to two.
{{ RFC Editor: please change proposes several changes to the to
changes the. }}
The IETF Secretariat.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-enum-iax-10.txt (IANA Registration for Enumservice 'iax') to Informational RFC
FWIW ... I reviewed this and thought it looked fine. On Apr 5, 2011, at 5:48 AM, The IESG wrote: The IESG has received a request from the Telephone Number Mapping WG (enum) to consider the following document: - 'IANA Registration for Enumservice 'iax'' draft-ietf-enum-iax-10.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-04-19. 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://datatracker.ietf.org/doc/draft-ietf-enum-iax/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-enum-iax/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-05
The last *several* revisions have been perfectly fine. The most recent edits are also fine. We're micro-editing this document at this point, meaning that perfect is impeding our ability to deploy more than good enough to replace 3-tier system that most IETF folks agree is broken, and has been broken for at least a decade. A tiny few people might like to edit this document more, but the IETF supposedly operates upon rough consensus, rather than either smooth consensus or unanimity. Could we please Last Call, approve, and ship this right now ? Yours, Ran Atkinson ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-05
On 06.04.2011 17:27, Russ Housley wrote: This revision proposes a solution to the issue raised by Brian Carpenter about documents lingering at Draft Standard. Some people thought it was a problem. Others thought it did not matter. The proposed solution leaves the matter in the hands of the IESG. Russ ... A question...: A specification shall remain at the Proposed Standard maturity level for at least six (6) months before consideration for advancement to the Internet Standard maturity level. It would probably good to clarify when the six month period starts (IESG approval? RFC publication?). Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-05
On 4/6/11 10:45 AM, Julian Reschke wrote: On 06.04.2011 17:27, Russ Housley wrote: This revision proposes a solution to the issue raised by Brian Carpenter about documents lingering at Draft Standard. Some people thought it was a problem. Others thought it did not matter. The proposed solution leaves the matter in the hands of the IESG. Russ ... A question...: A specification shall remain at the Proposed Standard maturity level for at least six (6) months before consideration for advancement to the Internet Standard maturity level. It would probably good to clarify when the six month period starts (IESG approval? RFC publication?). RFC publication seems sensible -- sometimes it can take more than six months between IESG approval and RFC publication! (Slow authors during AUTH48, dependencies on yet-to-be-published specs, etc.) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-05
Julian: A question...: A specification shall remain at the Proposed Standard maturity level for at least six (6) months before consideration for advancement to the Internet Standard maturity level. It would probably good to clarify when the six month period starts (IESG approval? RFC publication?). This is not a new question. It comes up every few years, and it was a big topic a few yers back when there was a long delay between approval and RFC publication. The 6 months starts with RFC publication. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-05
Russ == Russ Housley hous...@vigilsec.com writes: Russ The 6 months starts with RFC publication. Please say that in the draft then. I had a different take away from the last version of this discussion I participated in. I don't care much what the answer is, but it seems clear that it requires documentation. Apologies if it is already stated elsewhere in the draft: I have not read 05 yet. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-05
Sam and Julian: Russ == Russ Housley hous...@vigilsec.com writes: Russ The 6 months starts with RFC publication. Please say that in the draft then. I had a different take away from the last version of this discussion I participated in. I don't care much what the answer is, but it seems clear that it requires documentation. Apologies if it is already stated elsewhere in the draft: I have not read 05 yet. I will add a sentence in -06 to make this clear. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-05
On 2011-04-07 03:27, Russ Housley wrote: This revision proposes a solution to the issue raised by Brian Carpenter about documents lingering at Draft Standard. Some people thought it was a problem. Others thought it did not matter. The proposed solution leaves the matter in the hands of the IESG. That seems like a fine approach; it allows common sense to be applied. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Admin Plenary Minutes
http://www.ietf.org/proceedings/80/minutes/plenaryw.txt The Admin Plenary minutes are now available for review. Please let me know if there are any changes needed, Many thanks to Mirjam Kuehne for her help generating this minutes. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-siprec-req-09.txt (Use Cases and Requirements for SIP-based Media Recording (SIPREC)) to Informational RFC
The IESG has received a request from the SIP Recording WG (siprec) to consider the following document: - 'Use Cases and Requirements for SIP-based Media Recording (SIPREC)' draft-ietf-siprec-req-09.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-04-20. 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://datatracker.ietf.org/doc/draft-ietf-siprec-req/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ 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
Last Call: draft-ietf-vcarddav-vcardrev-17.txt (vCard Format Specification) to Proposed Standard
The IESG has received a request from the vCard and CardDAV WG (vcarddav) to consider the following document: - 'vCard Format Specification' draft-ietf-vcarddav-vcardrev-17.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-04-20. 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://datatracker.ietf.org/doc/draft-ietf-vcarddav-vcardrev/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-vcarddav-vcardrev/ 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
Last Call: draft-ietf-vcarddav-vcardxml-08.txt (vCard XML Representation) to Proposed Standard
The IESG has received a request from the vCard and CardDAV WG (vcarddav) to consider the following document: - 'vCard XML Representation' draft-ietf-vcarddav-vcardxml-08.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-04-20. 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://datatracker.ietf.org/doc/draft-ietf-vcarddav-vcardxml/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-vcarddav-vcardxml/ 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
Last Call: draft-ietf-dime-extended-naptr-06.txt (Diameter S-NAPTR Usage) to Proposed Standard
The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Diameter S-NAPTR Usage' draft-ietf-dime-extended-naptr-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 2011-04-20. 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://datatracker.ietf.org/doc/draft-ietf-dime-extended-naptr/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dime-extended-naptr/ 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
Last Call: draft-paxson-tcpm-rfc2988bis-02.txt (Computing TCP's Retransmission Timer) to Proposed Standard
The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'Computing TCP's Retransmission Timer' draft-paxson-tcpm-rfc2988bis-02.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-04-20. 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://datatracker.ietf.org/doc/draft-paxson-tcpm-rfc2988bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-paxson-tcpm-rfc2988bis/ 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
Last Call: draft-ietf-opsawg-mpls-tp-oam-def-09.txt (Guidelines for the use of the OAM acronym in the IETF) to BCP
The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'Guidelines for the use of the OAM acronym in the IETF' draft-ietf-opsawg-mpls-tp-oam-def-09.txt as a BCP 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-04-20. 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://datatracker.ietf.org/doc/draft-ietf-opsawg-mpls-tp-oam-def/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-opsawg-mpls-tp-oam-def/ 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
Last Call: draft-ietf-ippm-tcp-throughput-tm-12.txt (Framework for TCP Throughput Testing) to Informational RFC
The IESG has received a request from the IP Performance Metrics WG (ippm) to consider the following document: - 'Framework for TCP Throughput Testing' draft-ietf-ippm-tcp-throughput-tm-12.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-04-20. 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://datatracker.ietf.org/doc/draft-ietf-ippm-tcp-throughput-tm/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ippm-tcp-throughput-tm/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1319/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
