Syslog inquiry, what is TAG delimiter with regard to RFC 3164
Hello, We got a problem how to interpret the RFC 3164 document with respect to how to define the possible delimiters that can separate the TAG and CONTENT field. More specifically, is space a valid delimiter? The part in RFC 3164 that supports space as a valid delimiter is in section 4.1.3: The MSG part has two fields known as the TAG field and the CONTENT field. The value in the TAG field will be the name of the program or process that generated the message. The CONTENT contains the details of the message. This has traditionally been a freeform message that gives some detailed information of the event. The TAG is a string of ABNF alphanumeric characters that MUST NOT exceed 32 characters. Any non-alphanumeric character will terminate the TAG field and will be assumed to be the starting character of the CONTENT field. Most commonly, the first character of the CONTENT field that signifies the conclusion of the TAG field has been seen to be the left square bracket character ([), a colon character (:), or a space character. This is explained in more detail in Section 5.3. However, further down in the document you find evidence of the contrary, under 5.4 Examples, a message where Use could be considered as the TAG: Example 2 Use the BFG! While this is a valid message, it has extraordinarily little useful information. This message does not have any discernable PRI part. It does not contain a timestamp or any indication of the source of the message. If this message is stored on paper or disk, subsequent review of the message will not yield anything of value. This example is obviously an original message from a device. A relay MUST make changes to the message as described in Section 4.3 before forwarding it. The resulting relayed message is shown below. 13Feb 5 17:32:18 10.0.0.99 Use the BFG! In this relayed message, the entire message has been treated as the CONTENT portion of the MSG part. First, a valid PRI part has been added using the default priority value of 13. Next, a TIMESTAMP has been added along with a HOSTNAME in the HEADER part. Subsequent relays will not make any further changes to this message. It should be noted in this example that the day of the month is less than 10. Since single digits in the date (5 in this case) are preceded by a space in the TIMESTAMP format, there are two spaces following the month in the TIMESTAMP before the day of the month. Also, the relay appears to have no knowledge of the host name of the device sending the message so it has inserted the IPv4 address of the device into the HOSTNAME field. What is the general understanding of this issue? Regards, Johan Bosaeus Weird Solutions AB ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
Anthony G. Atkielski wrote: John Calcote writes: I'll just jump in here for a second and mention also that vendors offer what they have to, not what they can. They want to provide the most bang for the buck, so to speak. These companies don't offer the multiple-static-ip-address option today because most ISP's don't offer it to home users and home (SOHO) users represent the target market. It is unlikely that ISPs will ever offer static IPs or multiple IPs to home users at any time in the future for free. They will continue to charge heavy premiums for such professional features, with or without IPv6. http://www.manitu.de/ They offer you: fixed IPv4 address with reverse lookup at 9.99 Euros per month. You must have already T-DSL to use this servevice and you will keep that. Means the 9.99 Euros get you a second PPPoE link over your old modem and you can have a fixed plus a dynamic IPv4 address at one and the same time. t-online.de offer a similar service but it is more expensive. -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
Peter Dambier writes: http://www.manitu.de/ They offer you: fixed IPv4 address with reverse lookup at 9.99 Euros per month. I don't live in Germany. The exception does not disprove the rule. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
draft-ietf-dkim-threats-02 nit//Affects verification of messages?
, |1.2. Document Structure |... | | The sections dealing with attacks on DKIM each begin with a table | summarizing the postulated attacks in each category along with their | expected impact and likelihood. The following definitions were used | as rough criteria for scoring the attacks: | | Impact: | | High: Affects the verification of messages from an entire domain or | multiple domains ' It is not clear what is meant by affects verification of messages. The verification process depends only upon the integrity of the network infrastructure. The threat document should consider the impact upon the classification of a domain's messages. Even when a private key is compromised, the verification process still passes valid messages. The threat review indicates a compromised key as causing a high impact. One could conclude this impact results when messages from a bad actor accrue to the exploited domain. The introduction offers these possible uses of DKIM. , | Once the attesting party or parties have been established, the | recipient may evaluate the message in the context of additional | information such as locally-maintained whitelists, shared reputation | services, and/or third-party accreditation. ' A threat document should consider how an exploit might affect these uses of DKIM. Change: Affects the verification of messages... to Affects the classification of messages... -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Copyright status of early RFCs
A friend of mine wants to include copies of some early RFCs in a book. My understanding is that anything published before 1976 without a copyright notice, which would presumably include RFCs up through about number 700, is in the public domain. Does the IETF or IAB or RFC Editor take a position on this? Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor More Wiener schnitzel, please, said Tom, revealingly. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-pana-framework-06
Hi Bob, I think the issue at hand is not the interpretation of text, but the conflicting text in the 802.11i standard. David Nelson has already shed some light to this. Text in Clause 5 opens the door for non-802.1X protocols to utilize the uncontrolled port, and we didn't find any limitations on what those protocols may be -- hence concluded that PANA could be one of those. This is where PANA WG came from. I'd not say this is an interpretation, but rather spec-reading. How are we (in fact, IEEE) going to resolve this? Alper -Original Message- From: Bob O'Hara (boohara) [mailto:[EMAIL PROTECTED] Sent: Thursday, April 06, 2006 4:49 PM To: Alper Yegin; Yoshihiro Ohba; Sam Hartman Cc: ietf@ietf.org Subject: RE: Last Call: draft-ietf-pana-framework-06 Alper, In my reading of 802.11i, such an AP will not be compliant. In addition, PANA needs to have the 802.11 mobile client also support PANA. Currently, PANA packets would also be dropped at the sending client, prior to opening the 802.1X controlled port. In Yoshi's email, referenced at the URL below, he says that it is possible to interpret the text in the current 802.11ma revision draft to allow the PANA operations described for bootstrapping an 802.11i AP. The IEEE is the only body that has the authority to interpret their standards. For 802.11, IEEE delegates that authority to the working group that I chair. I can't forecast what an official interpretation response might say, but the text in clause 5 is taken from the overview section of the standard. The text prohibiting non-802.1X frames from passing on the uncontrolled port is taken from clause 6, the description of the Data SAP. My opinion would be that the text in clause 6 would be given precedence, both because of its placement and because of its specificity. -Bob O'Hara, Chair, 802.11 Task Group m -Original Message- From: Alper Yegin [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 22, 2006 11:55 AM To: Bob O'Hara (boohara); 'Yoshihiro Ohba'; 'Sam Hartman' Cc: ietf@ietf.org Subject: RE: Last Call: draft-ietf-pana-framework-06 Hi Bob, Last two e-mails were in response to Sam's implementability concern. Note that, when an IEEE 802.11 AP is used as a PANA EP and bootstrapped for IEEE 802.11i security, it is not an off-the-shelf AP. Some amount of coding needs to be done on the AP. The question is, would this modified AP still be compliant with IEEE 802.11i or not (no, PANA WG does not mean to propose a change to IEEE standards.) Please see Yoshi's e-mail and let us know what you think. http://www1.ietf.org/mail-archive/web/ietf/current/msg41011.html Thanks. Alper -Original Message- From: Bob O'Hara (boohara) [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 22, 2006 8:34 PM To: Alper Yegin; Yoshihiro Ohba; Sam Hartman Cc: ietf@ietf.org Subject: RE: Last Call: draft-ietf-pana-framework-06 I have no doubt that an implementation can be made to work, when one has control of all the layers. The question is whether PANA bootstrap will work when all that is supplied is a PANA layer that must operate above an existing, presumably standards compliant, 802.1X/802.11i implementation. When one can bypass a restriction of 802.11i (which says to drop non-802.1X frames on the uncontrolled port), then PANA bootstrap is possible. However, what authority has PANA to change a standard developed in an entirely different standards organization? -Bob -Original Message- From: Alper Yegin [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 22, 2006 7:19 AM To: 'Yoshihiro Ohba'; 'Sam Hartman' Cc: ietf@ietf.org Subject: RE: Last Call: draft-ietf-pana-framework-06 We (Samsung) have an implementation as well. Alper -Original Message- From: Yoshihiro Ohba [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 22, 2006 12:02 AM To: Sam Hartman Cc: ietf@ietf.org Subject: Re: Last Call: draft-ietf-pana-framework-06 If implementability of the specification is an issue, my company has an implementation of bootstrapping 802.11i PSK mode based on running PANA over Uncontrolled Port. The implementation works without modifying a WiFi hardware or its firmware. We have a plan to publish the source code of the implementation in Open Diameter project. Regards, Yoshihiro Ohba On Tue, Mar 21, 2006 at 11:45:25AM -0500, Sam Hartman wrote: Yoshihiro == Yoshihiro Ohba [EMAIL PROTECTED] writes: e email discussion over Yoshihiro the EAP mailing list quoted below, I had a short Yoshihiro conversation on this issue with Jesse Walker during Yoshihiro IEEE 802 interim meeting in January in order to Yoshihiro follow-up the email discussion and understand the input Yoshihiro from Jesse more. As far as I understand, he seemed to Yoshihiro agree on
RE: Last Call: draft-ietf-pana-framework-06
The official way to do this is to submit an interpretation request to the IEEE. The instructions can be found here: http://standards.ieee.org/reading/ieee/interp/. The request will then be referred to the appropriate working group for response and approval. The earliest that this could be completed by 802.11 is during their meeting during the week of May 14-18. This would result in an official response from the 802.11 working group and the IEEE. Generally, the response will include referral to the next maintenance task group for inclusion in a corrigendum or the next revision of the standard. -Bob -Original Message- From: Alper Yegin [mailto:[EMAIL PROTECTED] Sent: Thursday, April 06, 2006 4:22 PM To: Bob O'Hara (boohara); 'Yoshihiro Ohba'; 'Sam Hartman' Cc: ietf@ietf.org Subject: RE: Last Call: draft-ietf-pana-framework-06 Hi Bob, I think the issue at hand is not the interpretation of text, but the conflicting text in the 802.11i standard. David Nelson has already shed some light to this. Text in Clause 5 opens the door for non-802.1X protocols to utilize the uncontrolled port, and we didn't find any limitations on what those protocols may be -- hence concluded that PANA could be one of those. This is where PANA WG came from. I'd not say this is an interpretation, but rather spec-reading. How are we (in fact, IEEE) going to resolve this? Alper -Original Message- From: Bob O'Hara (boohara) [mailto:[EMAIL PROTECTED] Sent: Thursday, April 06, 2006 4:49 PM To: Alper Yegin; Yoshihiro Ohba; Sam Hartman Cc: ietf@ietf.org Subject: RE: Last Call: draft-ietf-pana-framework-06 Alper, In my reading of 802.11i, such an AP will not be compliant. In addition, PANA needs to have the 802.11 mobile client also support PANA. Currently, PANA packets would also be dropped at the sending client, prior to opening the 802.1X controlled port. In Yoshi's email, referenced at the URL below, he says that it is possible to interpret the text in the current 802.11ma revision draft to allow the PANA operations described for bootstrapping an 802.11i AP. The IEEE is the only body that has the authority to interpret their standards. For 802.11, IEEE delegates that authority to the working group that I chair. I can't forecast what an official interpretation response might say, but the text in clause 5 is taken from the overview section of the standard. The text prohibiting non-802.1X frames from passing on the uncontrolled port is taken from clause 6, the description of the Data SAP. My opinion would be that the text in clause 6 would be given precedence, both because of its placement and because of its specificity. -Bob O'Hara, Chair, 802.11 Task Group m -Original Message- From: Alper Yegin [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 22, 2006 11:55 AM To: Bob O'Hara (boohara); 'Yoshihiro Ohba'; 'Sam Hartman' Cc: ietf@ietf.org Subject: RE: Last Call: draft-ietf-pana-framework-06 Hi Bob, Last two e-mails were in response to Sam's implementability concern. Note that, when an IEEE 802.11 AP is used as a PANA EP and bootstrapped for IEEE 802.11i security, it is not an off-the-shelf AP. Some amount of coding needs to be done on the AP. The question is, would this modified AP still be compliant with IEEE 802.11i or not (no, PANA WG does not mean to propose a change to IEEE standards.) Please see Yoshi's e-mail and let us know what you think. http://www1.ietf.org/mail-archive/web/ietf/current/msg41011.html Thanks. Alper -Original Message- From: Bob O'Hara (boohara) [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 22, 2006 8:34 PM To: Alper Yegin; Yoshihiro Ohba; Sam Hartman Cc: ietf@ietf.org Subject: RE: Last Call: draft-ietf-pana-framework-06 I have no doubt that an implementation can be made to work, when one has control of all the layers. The question is whether PANA bootstrap will work when all that is supplied is a PANA layer that must operate above an existing, presumably standards compliant, 802.1X/802.11i implementation. When one can bypass a restriction of 802.11i (which says to drop non-802.1X frames on the uncontrolled port), then PANA bootstrap is possible. However, what authority has PANA to change a standard developed in an entirely different standards organization? -Bob -Original Message- From: Alper Yegin [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 22, 2006 7:19 AM To: 'Yoshihiro Ohba'; 'Sam Hartman' Cc: ietf@ietf.org Subject: RE: Last Call: draft-ietf-pana-framework-06 We (Samsung) have an implementation as well. Alper -Original Message- From: Yoshihiro Ohba [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 22, 2006 12:02 AM To: Sam Hartman Cc: ietf@ietf.org Subject: Re: Last Call: draft-ietf-pana-framework-06 If implementability of the specification is an issue, my company has
Re: Last Call: draft-ietf-pana-framework-06
Thanks for the URL to the interpretation request. The text in the URL says: Interpretations are issued to explain and clarify the intent of the standard and are not intended to constitute an alteration to the original standard or to supply consulting information. The interpretations subgroup cannot make new rules to fit situations not yet covered in the standard, even if the investigations of the subgroup lead it to conclude that the requirement is incomplete or in error. Changes to the standard are made only through revisions or supplements to the standard. The intent of the standard has been already clarified by David Nelson. TGi voted to accept the text proposed for the intent. So I don't expect the intent to be changed through the interpretation request procedure, while I expect the intent to be more clarified in the procedure. Best regards, Yoshihiro Ohba On Thu, Apr 06, 2006 at 04:28:07PM -0700, Bob O'Hara (boohara) wrote: The official way to do this is to submit an interpretation request to the IEEE. The instructions can be found here: http://standards.ieee.org/reading/ieee/interp/. The request will then be referred to the appropriate working group for response and approval. The earliest that this could be completed by 802.11 is during their meeting during the week of May 14-18. This would result in an official response from the 802.11 working group and the IEEE. Generally, the response will include referral to the next maintenance task group for inclusion in a corrigendum or the next revision of the standard. -Bob -Original Message- From: Alper Yegin [mailto:[EMAIL PROTECTED] Sent: Thursday, April 06, 2006 4:22 PM To: Bob O'Hara (boohara); 'Yoshihiro Ohba'; 'Sam Hartman' Cc: ietf@ietf.org Subject: RE: Last Call: draft-ietf-pana-framework-06 Hi Bob, I think the issue at hand is not the interpretation of text, but the conflicting text in the 802.11i standard. David Nelson has already shed some light to this. Text in Clause 5 opens the door for non-802.1X protocols to utilize the uncontrolled port, and we didn't find any limitations on what those protocols may be -- hence concluded that PANA could be one of those. This is where PANA WG came from. I'd not say this is an interpretation, but rather spec-reading. How are we (in fact, IEEE) going to resolve this? Alper -Original Message- From: Bob O'Hara (boohara) [mailto:[EMAIL PROTECTED] Sent: Thursday, April 06, 2006 4:49 PM To: Alper Yegin; Yoshihiro Ohba; Sam Hartman Cc: ietf@ietf.org Subject: RE: Last Call: draft-ietf-pana-framework-06 Alper, In my reading of 802.11i, such an AP will not be compliant. In addition, PANA needs to have the 802.11 mobile client also support PANA. Currently, PANA packets would also be dropped at the sending client, prior to opening the 802.1X controlled port. In Yoshi's email, referenced at the URL below, he says that it is possible to interpret the text in the current 802.11ma revision draft to allow the PANA operations described for bootstrapping an 802.11i AP. The IEEE is the only body that has the authority to interpret their standards. For 802.11, IEEE delegates that authority to the working group that I chair. I can't forecast what an official interpretation response might say, but the text in clause 5 is taken from the overview section of the standard. The text prohibiting non-802.1X frames from passing on the uncontrolled port is taken from clause 6, the description of the Data SAP. My opinion would be that the text in clause 6 would be given precedence, both because of its placement and because of its specificity. -Bob O'Hara, Chair, 802.11 Task Group m -Original Message- From: Alper Yegin [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 22, 2006 11:55 AM To: Bob O'Hara (boohara); 'Yoshihiro Ohba'; 'Sam Hartman' Cc: ietf@ietf.org Subject: RE: Last Call: draft-ietf-pana-framework-06 Hi Bob, Last two e-mails were in response to Sam's implementability concern. Note that, when an IEEE 802.11 AP is used as a PANA EP and bootstrapped for IEEE 802.11i security, it is not an off-the-shelf AP. Some amount of coding needs to be done on the AP. The question is, would this modified AP still be compliant with IEEE 802.11i or not (no, PANA WG does not mean to propose a change to IEEE standards.) Please see Yoshi's e-mail and let us know what you think. http://www1.ietf.org/mail-archive/web/ietf/current/msg41011.html Thanks. Alper -Original Message- From: Bob O'Hara (boohara) [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 22, 2006 8:34 PM To: Alper Yegin; Yoshihiro Ohba; Sam Hartman Cc: ietf@ietf.org Subject: RE: Last Call: draft-ietf-pana-framework-06 I have no doubt that an implementation can be made to work, when one has control of all the
Re: Guidance needed on well known ports
On Friday, March 24, 2006 08:23:20 AM -0500 Steven M. Bellovin [EMAIL PROTECTED] wrote: On Thu, 23 Mar 2006 20:56:51 -0800, Joe Touch [EMAIL PROTECTED] wrote: Since it seems like this might be useful, I'll pull a draft together on how to do this without 1078's extra connection, more like the late-binding we do in datarouter, very shortly... 1078 doesn't use an extra connection; it hands off the open connection to the protocol handler. Your suggestion of using a TCP option instead is friendlier to firewalls, though. And it uses fewer round trips. I like this idea. does require a mod to TCP to allow the dest port to be unbound (e.g., '0') if the option is present, and enable the return SYN-ACK to update the TCB on arrival. This part, though, seems like it could be perilous. Why not start with a non-zero port and hand off the connection, a la tcpmux? -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
On Thursday, March 23, 2006 09:40:06 PM -0800 Stuart Cheshire [EMAIL PROTECTED] wrote: Right now there are a couple of hundred application-layer protocols implemented that work this way. And wow is there a lot of MDNS broadcast traffic on my network. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-pana-framework-06
Yoshihiro, You say that the intent of the standard has been already clarified by David Nelson. This is incorrect. David has offered his opinion as an individual as to what he believes took place. He has no authority to interpret the intent of the standard. Only the working group can interpret the standard when there is an apparent ambiguity, as this situation appears. Basing the work of PANA on anything less would be very precarious, indeed. -Bob -Original Message- From: Yoshihiro Ohba [mailto:[EMAIL PROTECTED] Sent: Thursday, April 06, 2006 4:46 PM To: Bob O'Hara (boohara) Cc: Alper Yegin; Yoshihiro Ohba; Sam Hartman; ietf@ietf.org Subject: Re: Last Call: draft-ietf-pana-framework-06 Thanks for the URL to the interpretation request. The text in the URL says: Interpretations are issued to explain and clarify the intent of the standard and are not intended to constitute an alteration to the original standard or to supply consulting information. The interpretations subgroup cannot make new rules to fit situations not yet covered in the standard, even if the investigations of the subgroup lead it to conclude that the requirement is incomplete or in error. Changes to the standard are made only through revisions or supplements to the standard. The intent of the standard has been already clarified by David Nelson. TGi voted to accept the text proposed for the intent. So I don't expect the intent to be changed through the interpretation request procedure, while I expect the intent to be more clarified in the procedure. Best regards, Yoshihiro Ohba On Thu, Apr 06, 2006 at 04:28:07PM -0700, Bob O'Hara (boohara) wrote: The official way to do this is to submit an interpretation request to the IEEE. The instructions can be found here: http://standards.ieee.org/reading/ieee/interp/. The request will then be referred to the appropriate working group for response and approval. The earliest that this could be completed by 802.11 is during their meeting during the week of May 14-18. This would result in an official response from the 802.11 working group and the IEEE. Generally, the response will include referral to the next maintenance task group for inclusion in a corrigendum or the next revision of the standard. -Bob -Original Message- From: Alper Yegin [mailto:[EMAIL PROTECTED] Sent: Thursday, April 06, 2006 4:22 PM To: Bob O'Hara (boohara); 'Yoshihiro Ohba'; 'Sam Hartman' Cc: ietf@ietf.org Subject: RE: Last Call: draft-ietf-pana-framework-06 Hi Bob, I think the issue at hand is not the interpretation of text, but the conflicting text in the 802.11i standard. David Nelson has already shed some light to this. Text in Clause 5 opens the door for non-802.1X protocols to utilize the uncontrolled port, and we didn't find any limitations on what those protocols may be -- hence concluded that PANA could be one of those. This is where PANA WG came from. I'd not say this is an interpretation, but rather spec-reading. How are we (in fact, IEEE) going to resolve this? Alper -Original Message- From: Bob O'Hara (boohara) [mailto:[EMAIL PROTECTED] Sent: Thursday, April 06, 2006 4:49 PM To: Alper Yegin; Yoshihiro Ohba; Sam Hartman Cc: ietf@ietf.org Subject: RE: Last Call: draft-ietf-pana-framework-06 Alper, In my reading of 802.11i, such an AP will not be compliant. In addition, PANA needs to have the 802.11 mobile client also support PANA. Currently, PANA packets would also be dropped at the sending client, prior to opening the 802.1X controlled port. In Yoshi's email, referenced at the URL below, he says that it is possible to interpret the text in the current 802.11ma revision draft to allow the PANA operations described for bootstrapping an 802.11i AP. The IEEE is the only body that has the authority to interpret their standards. For 802.11, IEEE delegates that authority to the working group that I chair. I can't forecast what an official interpretation response might say, but the text in clause 5 is taken from the overview section of the standard. The text prohibiting non-802.1X frames from passing on the uncontrolled port is taken from clause 6, the description of the Data SAP. My opinion would be that the text in clause 6 would be given precedence, both because of its placement and because of its specificity. -Bob O'Hara, Chair, 802.11 Task Group m -Original Message- From: Alper Yegin [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 22, 2006 11:55 AM To: Bob O'Hara (boohara); 'Yoshihiro Ohba'; 'Sam Hartman' Cc: ietf@ietf.org Subject: RE: Last Call: draft-ietf-pana-framework-06 Hi Bob, Last two e-mails were in response to Sam's implementability concern. Note that, when an IEEE 802.11 AP is used as a PANA EP and bootstrapped for IEEE 802.11i security, it is not an off-the-shelf AP. Some amount of
Seeking... IAB Executive Director
All, The IAB is currently looking to appoint an Executive Director. The Executive Director is a non-voting ex-officio member of the IAB. (See RFC2850, the IAB's charter, for details). We are looking for suggestions, based on the brief profile for the role, below. We would like you to consider this profile and either suggest yourself or other people that you think that would fit well in this role by sending mail to the IAB at [EMAIL PROTECTED] We do not intend to disclose the names of the nominees in public, but we may wish to discuss this issue with third parties such as the Area Directors. If you have a problem with your name being mentioned in this context, please let us know. Note that this profile is written for a somewhat ideal candidate. We fully realize that such people are probably non-existent. So don't hesitate to suggest somebody who in your opinion would fit this role but might not meet all the qualifications 100 percent. Here is the profile: - Writing skills. The Executive Director keeps and edits the minutes of the IAB meetings and prepares them for public dissemination. - Sysadmin skills. The Executive Director handles the administration of the IAB websites, including the maintenance of tools such as Wikis, Jabber servers, email lists, etc. - IETF experience. It is desirable for the candidate to have at least some experience with the IETF. - Organizational skills. The Executive Director serves as a program manager for IAB work items. It is desirable for the candidate to be able to juggle many outstanding tasks simultaneously. - Enough time available. For example, it is preferable that the candidate not be chair of more than one IETF WG, or a member of the IESG or IAB. We would like to receive your comments suggestions by April 14th 2006 and we plan to make a decision as soon as possible thereafter. It will be helpful if you indicate in your email how you or the suggested person fits this profile as best as possible. Leslie Daigle, for The IAB. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Jeffrey Hutzelman wrote: On Friday, March 24, 2006 08:23:20 AM -0500 Steven M. Bellovin [EMAIL PROTECTED] wrote: On Thu, 23 Mar 2006 20:56:51 -0800, Joe Touch [EMAIL PROTECTED] wrote: Since it seems like this might be useful, I'll pull a draft together on how to do this without 1078's extra connection, more like the late-binding we do in datarouter, very shortly... 1078 doesn't use an extra connection; it hands off the open connection to the protocol handler. Your suggestion of using a TCP option instead is friendlier to firewalls, though. And it uses fewer round trips. I like this idea. does require a mod to TCP to allow the dest port to be unbound (e.g., '0') if the option is present, and enable the return SYN-ACK to update the TCB on arrival. This part, though, seems like it could be perilous. Why not start with a non-zero port and hand off the connection, a la tcpmux? TCPMUX doesn't 'handoff'. It expects that either the connection is closed and another is opened, or that the service desired is served off of its port once opened after the initial exchange (in-band). The latter is a possibility here. The downside is that it then forces a two-step demultiplexing of incoming packets; there may be utility in a variant that allows the dest port to be unbound and later filled-in, or changed during the connection, so that services can be more efficiently demultiplexed. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
From: Joe Touch [EMAIL PROTECTED] TCPMUX doesn't 'handoff'. It expects that .. the service desired is served off of its port once opened after the initial exchange (in-band). .. The downside is that it then forces a two-step demultiplexing of incoming packets; there may be utility in a variant that allows the dest port to be unbound and later filled-in, or changed during the connection, so that services can be more efficiently demultiplexed. I'm missing something here. A TCP connection is identified by the (srcaddr, sport, dstaddr, dport) tuple. TCB's are looked up by this tuple. Connections to TCPMUX will all have the same dstaddr/dport, but will presumably have different srcaddr's, and (presumably) random sport's, and can be distinguished that way. Why can't the TCPMUX listener just bind the correct application to the TCB (after figuring out what the appropriate application is), and then forget about the connection, leaving it entirely to the application to deal with? All packets which belong to that connection will automatically go to that TCB, and thence to the application, with no second layer of demux needed. Am I missing something? Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
On Apr 6, 2006, at 6:37 PM, Noel Chiappa wrote: Why can't the TCPMUX listener just bind the correct application to the TCB (after figuring out what the appropriate application is), and then forget about the connection, leaving it entirely to the application to deal with? All packets which belong to that connection will automatically go to that TCB, and thence to the application, with no second layer of demux needed. Am I missing something? On BSD and Solaris you can just pass the file descriptor from the new connection to the already running server. --lyndon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
On Thu, 6 Apr 2006 21:37:49 -0400 (EDT), [EMAIL PROTECTED] (Noel Chiappa) wrote: From: Joe Touch [EMAIL PROTECTED] TCPMUX doesn't 'handoff'. It expects that .. the service desired is served off of its port once opened after the initial exchange (in-band). .. The downside is that it then forces a two-step demultiplexing of incoming packets; there may be utility in a variant that allows the dest port to be unbound and later filled-in, or changed during the connection, so that services can be more efficiently demultiplexed. I'm missing something here. A TCP connection is identified by the (srcaddr, sport, dstaddr, dport) tuple. TCB's are looked up by this tuple. Connections to TCPMUX will all have the same dstaddr/dport, but will presumably have different srcaddr's, and (presumably) random sport's, and can be distinguished that way. Why can't the TCPMUX listener just bind the correct application to the TCB (after figuring out what the appropriate application is), and then forget about the connection, leaving it entirely to the application to deal with? All packets which belong to that connection will automatically go to that TCB, and thence to the application, with no second layer of demux needed. Am I missing something? No -- that's precisely how it works. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last Call: 'IPsec Security Policy Database Configuration MIB' to Proposed Standard
The IESG has received a request from the IP Security Policy WG to consider the following document: - 'IPsec Security Policy Database Configuration MIB ' draft-ietf-ipsp-spd-mib-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 any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-04-20. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsp-spd-mib-05.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
