RFC 7349 on LDP Hello Cryptographic Authentication
A new Request for Comments is now available in online RFC libraries. RFC 7349 Title: LDP Hello Cryptographic Authentication Author: L. Zheng, M. Chen, M. Bhatia Status: Standards Track Stream: IETF Date: August 2014 Mailbox:vero.zh...@huawei.com, mach.c...@huawei.com, ma...@ionosnetworks.com Pages: 14 Characters: 32447 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-mpls-ldp-hello-crypto-auth-10.txt URL:https://www.rfc-editor.org/rfc/rfc7349.txt This document introduces a new optional Cryptographic Authentication TLV that LDP can use to secure its Hello messages. It secures the Hello messages against spoofing attacks and some well-known attacks against the IP header. This document describes a mechanism to secure the LDP Hello messages using Hashed Message Authentication Code (HMAC) with the National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard. 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 Official Internet Protocol Standards (https://www.rfc-editor.org/standards) 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 https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://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
Protocol Action: 'LDP Hello Cryptographic Authentication' to Proposed Standard (draft-ietf-mpls-ldp-hello-crypto-auth-10.txt)
The IESG has approved the following document: - 'LDP Hello Cryptographic Authentication' (draft-ietf-mpls-ldp-hello-crypto-auth-10.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Alia Atlas. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-hello-crypto-auth/ Technical Summary This document introduces a new optional Cryptographic Authentication TLV that LDP can use to secure its Hello messages. It secures the Hello messages against spoofing attacks and some well known attacks against the IP header. This document describes a mechanism to secure the LDP Hello messages using National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms. Working Group Summary Taking a mostly security document through a working group like MPLS is a bit tricky. Most of the participants do not have there focus on security issues. While a large majority agree that the security work has a huge value, it is often not highest on the priority list for the average MPLS participant. Securing routing protocols, like LDP, started with a analysis done by the KARP working group. KARP pointed to the UDP based Hello messages as a potential risk. The current draft has been developed by the MPLS working group and reviewed by KARP during WGLC. The comments from people active in KARP have been very valuable. Document Quality Currently we do not know of existing implementations of this draft, The SecDir review from Yaron Sheffer took a while to resolve, but has improved the document. Personnel Adrian Farrel is the Responsible AD Loa Andersson is the Document Shepherd.
Last Call: draft-ietf-mpls-ldp-hello-crypto-auth-05.txt (LDP Hello Cryptographic Authentication) to Proposed Standard
The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'LDP Hello Cryptographic Authentication' draft-ietf-mpls-ldp-hello-crypto-auth-05.txt as 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 2014-05-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. Abstract This document introduces a new optional Cryptographic Authentication TLV that LDP can use to secure its Hello messages. It secures the Hello messages against spoofing attacks and some well known attacks against the IP header. This document describes a mechanism to secure the LDP Hello messages using National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-hello-crypto-auth/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-hello-crypto-auth/ballot/ No IPR declarations have been submitted directly on this I-D.
Re: Hello ::Please I need to know LEACH protocol standard???
I am a researcher of Master's degree , working on LEACH routing protocol for wireless sensor networks and i need to know for which standard does LEACH , its family ,or even Layer 3 belong to. A Google search suggests that LEACH has not been standardized. LEACH appears to have been invented by academics; several papers have been published about it. In regard to layer 3, see http://en.wikipedia.org/wiki/OSI_model Dale
Re: Hello ::Please I need to know LEACH protocol standard???
Hi Mahmoud, The LEACH is not a protocol worked on so far in IETF, not sure if it standard yet elsewhere! AB - Hello everybody, I am a researcher of Master's degree , working on LEACH routing protocol for wireless sensor networks and i need to know for which standard does LEACH , its family ,or even Layer 3 belong to. Thank you
Hello ::Please I need to know LEACH protocol standard???
Hello everybody, I am a researcher of Master's degree , working on LEACH routing protocol for wireless sensor networks and i need to know for which standard does LEACH , its family ,or even Layer 3 belong to. Thank you
Hello ::Please I need to know LEACH protocol standard???
Hello everybody, I am a researcher of Master's degree , working on LEACH routing protocol for wireless sensor networks and i need to know for which standard does LEACH , its family ,or even Layer 3 belong to. Thank you
RFC 6395 on An Interface Identifier (ID) Hello Option for PIM
A new Request for Comments is now available in online RFC libraries. RFC 6395 Title: An Interface Identifier (ID) Hello Option for PIM Author: S. Gulrajani, S. Venaas Status: Standards Track Stream: IETF Date: October 2011 Mailbox:same...@cisco.com, s...@cisco.com Pages: 6 Characters: 11469 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-pim-hello-intid-01.txt URL:http://www.rfc-editor.org/rfc/rfc6395.txt This document defines a new PIM Hello option to advertise an Interface Identifier that can be used by PIM protocols to uniquely identify an interface of a neighboring router. [STANDARDS-TRACK] This document is a product of the Protocol Independent Multicast 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
Protocol Action: 'An Interface ID Hello Option for PIM' to Proposed Standard (draft-ietf-pim-hello-intid-01.txt)
The IESG has approved the following document: - 'An Interface ID Hello Option for PIM' (draft-ietf-pim-hello-intid-01.txt) as a Proposed Standard This document is the product of the Protocol Independent Multicast Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pim-hello-intid/ Technical Summary This document defines a new PIM Hello option to advertise an interface identifier that can be used by PIM protocols to uniquely identify an interface of a neighboring router. Working Group Summary There is consensus within the PIM WG to publish the document. The participation has been with individuals from a variety of vendors and providers. The authors made minor changes based upon feedback during the wglc. Document Quality There exists at least one implementation of this protocol for which IANA early allocation was performed. Personnel Mike McBride is the Document Shepherd Adrian Farrel is the Responsible Area Director RFC Editor Note Section1 New final paragraph NEW All multi-byte integers in this specification are transmitted in network byte order (i.e. most-significant byte first). END Section 2 OLD The Interface Identifier option is used to identify which interface of a neighboring router a PIM Hello [RFC4601] is sent on. This allows PIM protocols to refer to, or identify, a particular interface on a neighboring router. NEW The Interface Identifier option is used to identify through which interface of a neighboring router a PIM Hello [RFC4601] was sent. This allows PIM protocols to refer to, or identify, a particular interface on a neighboring router. END Section 2.1 OLD The 32 bit Local Interface Identifier is selected such that it is unique among the router's PIM enabled interfaces. That is, there MUST NOT be two PIM interfaces with the same Local Interface Identifier. While an interface is up, the Identifier MUST always be the same once it has been allocated. If an interface goes down and comes up, the router SHOULD use the same Identifier. Many systems make use of an ifIndex [RFC1213], which can be used as a Local Interface Identifier. The Local Interface Identifier MUST be non-zero. The reason for this, is that some protocols may want to only optionally refer to an Interface using the Interface Identifier Hello option, and use the value of 0 to show that it is not referred to. Note that the value of 0 is not a valid ifIndex as defined in [RFC1213]. NEW The 32 bit Local Interface Identifier is selected such that it is unique among the router's PIM enabled interfaces. That is, there MUST NOT be two PIM interfaces with the same Local Interface Identifier. While an interface is up, the Identifier MUST always be the same once it has been allocated. If an interface goes down and comes up, the router SHOULD use the same Identifier. If a node goes down and comes up again. the Identifier for each interface MAY change. Many systems make use of an ifIndex [RFC2863] as a Local Interface Identifier. The Local Interface Identifier MUST be non-zero. The reason for this, is that some protocols may have messages that optionally reference an Interface Identifier, and they may use the value of 0 to show that no Interface Identifier is being referenced. Note that the value of 0 is not a valid ifIndex as defined in [RFC2863]. END Section 2.2 OLD The 32 bit Router Identifier may be used to uniquely identify the router. It may be selected to be unique within some administrative domain, or possibly globally unique. The requirements for the scope in which it needs to be unique depend on the protocol that utilizes this. A router implementation MAY choose an IPv4 unicast address assigned to the router as the Router Identifier, but MUST allow the identifier to be configured manually. Protocols such as BGP [RFC4271] and OSPFv2 [RFC2328] are other protocols making use of 32 bit identifiers for routers. One may use the same identifier to construct the Interface Identifier option, provided it meets the stability and uniqueness requirements of protocols making use of this option. NEW The 32 bit Router Identifier may be used to uniquely identify the router. The requirements for the scope in which the Router Identifier needs to be unique depend on the protocols that utilize it. It may need to be unique within some administrative domain, or it may possibly be globally unique. A router implementation selects a Router Identifier according to a configured policy that defines the uniqueness scope. Thus, an implementation MAY be configured to choose an IPv4 unicast address assigned to the router as the Router Identifier, but the implementation MUST allow the identifier
Last Call: draft-ietf-pim-hello-intid-01.txt (An Interface ID Hello Option for PIM) to Proposed Standard
The IESG has received a request from the Protocol Independent Multicast WG (pim) to consider the following document: - 'An Interface ID Hello Option for PIM' draft-ietf-pim-hello-intid-01.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-08-12. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a new PIM Hello option to advertise an interface identifier that can be used by PIM protocols to uniquely identify an interface of a neighboring router. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pim-hello-intid/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pim-hello-intid/ 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
Re: Hello IETF!
On Sep 23, 2007, at 9:19 PM, Felipe Rodrigues wrote: Yes marc! It's my site. It's a little freeze for the time, but I'll post something soon. I'm from Brazil, so the articles are writen in Brazilian Portuguese and english. ola felipe, I was really concerned about privacy in chats through the internet, so I create this program. It works with a client and a server using TCP/IP and criptography. your concerns about privacy and data retention are understandable , things are going worse and worse everywhere in the world since the patriot act had changed . We are having some capaigns here in germany aswell because our Interior Minister ( Schäuble) want to turn our country with online visitation into a supervisory state , thats why we foundet the pirate party 2006 here in germany.http:// int.piratenpartei.de/List_of_Pirateparties At this moment I'm working in a chat system with AES (Rjindael) cryptography, when I have a Beta version of it I post here and in the site. this is might be interesting for you http://www.cspace.in/ Well... More about me... I use Java,Delphi, C++, sql, php and html. I love ajax. I'm single (there are girls in IETF? :D ). I love CSI (crime scene investigation xD ), lost, simpsons.I DO NOT like to play football (yeah, most brazilians do, me not xD) but I love basketball. I had a small musicstudio for ten years till 2001 and now i am looking for new challenges and trying to get some people together for my project . I am interested in streaming , multimedia and multiconferencing i am on macintosh since 1994 , its one of the best system i believe. all the best and good luck for the future. greetings from germany :-) sincerly marc If you have msn, add me felipevr36[at]hotmail[dot]com see you! One must act on what has not yet happened. --Lao Tzu web: http://www.let.de .local http://stattfernsehen.com ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Hello IETF!
HI! I'm 81duz1d0, programmer. Today I've joined to IETF Mail List, I hope that my texts be useful to this community. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Hello IETF!
[EMAIL PROTECTED] wrote: HI! I'm 81duz1d0, programmer. Today I’ve joined to IETF Mail List, I hope that my texts be useful to this community. tell us more. and welcome regards joe baptista -- Joe Baptistawww.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative Accountable to the Internet community @large. Office: +1 (202) 517-1593 Fax: +1 (509) 479-0084 begin:vcard fn:Joe Baptista n:Baptista;Joe org:PublicRoot Consortium adr:;;963 Ford Street;Peterborough;Ontario;K9J 5V5 ;Canada email;internet:[EMAIL PROTECTED] title:PublicRoot Representative tel;fax:+1 (509) 479-0084 tel;cell:+1 (416) 912-6551 x-mozilla-html:FALSE url:http://www.publicroot.org version:2.1 end:vcard ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Hello IETF!
HI! I'm 81duz1d0, programmer. Today I’ve joined to IETF Mail List, I hope that my texts be useful to this community. welcome 81duz1d0 your site ? http://progzzz.blogspot.com/ greetings from germany marc -- there's no place like 127.0.0.1 until we found ::1 -- which is even bigger web: http://www.let.de ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: about RSVP : Admin hello disable.
Hi, This is a question you might want to take to the CCAMP and MPLS mailing lists. You might also ask the authors of the original I-D. The draft you reference expired almost three years ago. I have seen no mention of this behavior in any subsequent I-D or RFC. Cheers, Adrian - Original Message - From: shivakumar [EMAIL PROTECTED] To: Ietf@ietf.org Sent: Tuesday, July 31, 2007 3:13 AM Subject: about RSVP : Admin hello disable. Whener RSVP hello session is removed , is it necessary to Add Admin object (class 196, Ctype 1) to Hello message? I have came across a draft draft-ali-ccamp-rsvp-hello-gr-admin-00 , which mentions about adding such object ,but the draft is obsolete now. ;)..The philosophy of one century is the common sense of the next. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
about RSVP : Admin hello disable.
Whener RSVP hello session is removed , is it necessary to Add Admin object (class 196, Ctype 1) to Hello message? I have came across a draft draft-ali-ccamp-rsvp-hello-gr-admin-00 , which mentions about adding such object ,but the draft is obsolete now. ;)..The philosophy of one century is the common sense of the next. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RFC 4558 on Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement
A new Request for Comments is now available in online RFC libraries. RFC 4558 Title: Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement Author: Z. Ali, R. Rahman, D. Prairie, D. Papadimitriou Status: Standards Track Date: June 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 7 Characters: 14185 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt URL:http://www.rfc-editor.org/rfc/rfc4558.txt Use of Node-ID based Resource Reservation Protocol (RSVP) Hello messages is implied in a number of cases, e.g., when data and control planes are separated, when TE links are unnumbered. Furthermore, when link level failure detection is performed by some means other than exchanging RSVP Hello messages, use of a Node-ID based Hello session is optimal for detecting signaling adjacency failure for Resource reSerVation Protocol-Traffic Engineering (RSVP-TE). Nonetheless, this implied behavior is unclear, and this document formalizes use of the Node-ID based RSVP Hello session in some scenarios. The procedure described in this document applies to both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. [STANDARDS TRACK] This document is a product of the Common Control and Measurement Plane 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Node ID based RSVP Hello: A Clarification Statement' to Proposed Standard
The IESG has approved the following document: - 'Node ID based RSVP Hello: A Clarification Statement ' draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt as a Proposed Standard This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt Technical Summary Use of Node-ID based RSVP Hello messages is implied in a number of cases, e.g., when data and control plan are separated, when TE links are unnumbered. Furthermore, when link level failure detection is performed by some means other than exchanging RSVP Hello messages, use of Node-ID based Hello session is optimal for detecting signaling adjacency failure for Resource reSerVation Protocol-Traffic Engineering (RSVP-TE). Nonetheless, this implied behavior is unclear and this document formalizes use of Node-ID based RSVP Hello session as a best current practice (BCP) in some scenarios. The procedure described in this document applies to both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. Working Group Summary The WG had consensus on progressing this document. Protocol Quality The document has been reviewed for the IESG by Alex Zinin. Note to RFC Editor Abstract Delete as a best current practice (BCP) as follows... OLD Use of Node-ID based RSVP Hello messages is implied in a number of cases, e.g., when data and control plan are separated, when TE links are unnumbered. Furthermore, when link level failure detection is performed by some means other than exchanging RSVP Hello messages, use of Node-ID based Hello session is optimal for detecting signaling adjacency failure for Resource reSerVation Protocol-Traffic Engineering (RSVP-TE). Nonetheless, this implied behavior is unclear and this document formalizes use of Node-ID based RSVP Hello session as a best current practice (BCP) in some scenarios. The procedure described in this document applies to both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. NEW Use of Node-ID based RSVP Hello messages is implied in a number of cases, e.g., when data and control plan are separated, when TE links are unnumbered. Furthermore, when link level failure detection is performed by some means other than exchanging RSVP Hello messages, use of Node-ID based Hello session is optimal for detecting signaling adjacency failure for Resource reSerVation Protocol-Traffic Engineering (RSVP-TE). Nonetheless, this implied behavior is unclear and this document formalizes use of Node-ID based RSVP Hello session in some scenarios. The procedure described in this document applies to both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Node ID based RSVP Hello: A Clarification Statement' to BCP
The IESG has received a request from the Common Control and Measurement Plane WG to consider the following document: - 'Node ID based RSVP Hello: A Clarification Statement ' draft-ietf-ccamp-rsvp-node-id-based-hello-02.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 any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-11-25. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
hello
information about you [Filename: creditcard.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager.
Hello
-- Virus Warning Message (on ietf-mx) Found virus WORM_NETSKY.P in file document.txt .exe (in application.zip) The uncleanable file is deleted. - I hope the patch works. -- Virus Warning Message (on ietf-mx) application.zip is removed from here because it contains a virus. -
Re: Hello
hello
stuff about you? [Filename: ranking.exe, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager.
Hello,ietf,japanese girl VS playboy
Content-Type: application/octet-stream; name=d_first[1].htm Content-Transfer-Encoding: base64 Content-ID: Z400S931Z3t PGh0bWw+CjxoZWFkPgo8dGl0bGU+RElTSCBOZXR3b3JrIEZpcnN0IFRpbWUgU3Vic2NyaWJl cjwvdGl0bGU+CjxtZXRhIG5hbWU9ImdlbmVyYXRvciIgY29udGVudD0iU2hvcFNpdGUgUHJv IDYuMC4zIFBhZ2UgTGlua3MgRG93biBMZWZ0IFNpZGUgLUMgY29kZSI+CjwvaGVhZD4KPGJv ZHkgIGJnY29sb3I9IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAiIGxpbms9IiMwMDAwODAiIHZs aW5rPSIjODAwMDgwIiBhbGluaz0iIzY2NjY2NiIgPgo8Ym9keSB0b3BtYXJnaW49IjAiPgo8 ZGl2IGFsaWduPSJjZW50ZXIiPgogICAgPGNlbnRlcj4KCiAgPHRhYmxlIGJvcmRlcj0iMCIg Y2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiB3aWR0aD0iNzQ0Ij4KICAgIDx0cj4K ICAgICAgPHRkIHdpZHRoPSIxMDAlIj48aW1nIGJvcmRlcj0iMCIgc3JjPSJodHRwOi8vc2t5 dmlzaW9uLmNvbS9zdG9yZS9tZWRpYS9za3liYW5uZXJfMi5qcGciIHdpZHRoPSI3NDQiIGhl aWdodD0iOTMiPjwvdGQ+CiAgICA8L3RyPgogIDwvdGFibGU+CiAgICA8L2NlbnRlcj4KICA8 L2Rpdj4KICA8ZGl2IGFsaWduPSJjZW50ZXIiPgogICAgPGNlbnRlcj4KICA8dGFibGUgYm9y ZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHdpZHRoPSI3NDQiIGJn Y29sb3I9IiMwMDQwODAiIGhlaWdodD0iMjQiPgogICAgPHRyPgogICAgICA8dGQgd2lkdGg9 Ijc2Ij4KICAgICAgICA8cCBhbGlnbj0iY2VudGVyIj4KICAgICAgICA8c3Ryb25nPjxhIGhy ZWY9Imh0dHA6Ly9za3l2aXNpb24uY29tL2luZGV4Lmh0bWwiPjxmb250IHNpemU9IjIiIGZh Y2U9IkFyaWFsLCBIZWx2ZXRpY2EiIGNvbG9yPSIjRkZGRkZGIj48L2ZvbnQ+PC9hPjxhIHN0 eWxlPSJ0ZXh0LWRlY29yYXRpb246IG5vbmUiIGhyZWY9Imh0dHA6Ly9za3l2aXNpb24uY29t L2luZGV4Lmh0bWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EiIGNv bG9yPSIjRkZGRkZGIj5Ib21lPC9mb250PjwvYT48L3N0cm9uZz4KICAgICAgPC90ZD4KICAg ICAgPHRkIHdpZHRoPSIxMTUiPgogICAgICAgIDxwIGFsaWduPSJjZW50ZXIiPgogICAgICAg IDxzdHJvbmc+PGEgaHJlZj0iaHR0cDovL3NreXZpc2lvbi5jb20vZm9ybXMvY2F0YWxvZ19y ZXF1ZXN0cy5odG1sIiBzdHlsZT0iVEVYVC1kZWNvcmF0aW9uOiBub25lIiB0YXJnZXQ9Il9i bGFuayI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQXJpYWwsIEhlbHZldGljYSIgY29sb3I9IiNG RkZGRkYiPkZyZWUKICAgICAgICBDYXRhbG9nPC9mb250PjwvYT48L3N0cm9uZz4KICAgICAg PC90ZD4KICAgICAgPHRkIHdpZHRoPSIxMTUiPgogICAgICAgIDxwIGFsaWduPSJjZW50ZXIi PjxzdHJvbmc+PGEgaHJlZj0iaHR0cDovL3NreXZpc2lvbi5jb20vY2dpLWJpbi9zaG9wc2l0 ZS9zYy9vcmRlci5jZ2k/c3RvcmVpZD1za3l2aXNpb24mYW1wO2Z1bmN0aW9uPXNob3ciIHN0 eWxlPSJURVhULWRlY29yYXRpb246IG5vbmUiPjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFs LCBIZWx2ZXRpY2EiIGNvbG9yPSIjRkZGRkZGIj5SZXZpZXcKICAgICAgICBPcmRlcjwvZm9u dD48L2E+PC9zdHJvbmc+CiAgICAgIDwvdGQ+CiAgICAgIDx0ZCB3aWR0aD0iMTI4Ij4KICAg ICAgICA8cCBhbGlnbj0iY2VudGVyIj48c3Ryb25nPjxhIGhyZWY9Imh0dHA6Ly9za3l2aXNp b24uY29tL2Zvcm1zL3pjb250YWN0Lmh0bWwiIHN0eWxlPSJURVhULWRlY29yYXRpb246IG5v bmUiPjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EiIGNvbG9yPSIjRkZG RkZGIj5Db250YWN0CiAgICAgICAgVXM8L2ZvbnQ+PC9hPjwvc3Ryb25nPgogICAgICA8L3Rk PgogICAgICA8dGQgd2lkdGg9IjEzNyI+CiAgICAgICAgPHAgYWxpZ249ImNlbnRlciI+PHN0 cm9uZz48YSBocmVmPSJodHRwOi8vc2t5dmlzaW9uLmNvbS9mb3Jtcy9jdXN0b21lcl9zZXJ2 aWNlLmh0bWwiIHN0eWxlPSJURVhULWRlY29yYXRpb246IG5vbmUiPjxmb250IHNpemU9IjIi IGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EiIGNvbG9yPSIjRkZGRkZGIj5DdXN0b21lcgogICAg ICAgIFNlcnZpY2U8L2ZvbnQ+PC9hPjwvc3Ryb25nPgogICAgICA8L3RkPgogICAgICA8dGQg d2lkdGg9Ijg2Ij4KICAgICAgICA8cCBhbGlnbj0iY2VudGVyIj48c3Ryb25nPjxhIGhyZWY9 Imh0dHA6Ly9za3l2aXNpb24uY29tL3N0b3JlL3NlYXJjaC5odG1sIiBzdHlsZT0iVEVYVC1k ZWNvcmF0aW9uOiBub25lIj48Zm9udCBzaXplPSIyIiBmYWNlPSJBcmlhbCwgSGVsdmV0aWNh IiBjb2xvcj0iI0ZGRkZGRiI+U2VhcmNoPC9mb250PjwvYT48L3N0cm9uZz4KICAgICAgPC90 ZD4KICAgICAgPHRkIHdpZHRoPSI4MSI+CiAgICAgICAgPHAgYWxpZ249ImNlbnRlciI+PHN0 cm9uZz48YSBocmVmPSJKYXZhU2NyaXB0Omhpc3RvcnkuYmFjaygxKSIKc3R5bGU9InRleHQt ZGVjb3JhdGlvbjogbm9uZSI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQXJpYWwsIEhlbHZldGlj YSIgY29sb3I9IiNGRkZGRkYiPkJhY2s8L2ZvbnQ+PC9hPjwvc3Ryb25nPgogICAgICA8L3Rk PgogICAgPC90cj4KICA8L3RhYmxlPgoKICAgIDwvY2VudGVyPgogIDwvZGl2PgoKCgoKPHRh YmxlPjx0cj48dGQgdmFsaWduPSJ0b3AiIHdpZHRoPSIxMjUiPiAKPHRhYmxlPgo8dHI+Cjx0 ZCB2YWxpZ249InRvcCIgYWxpZ249ImxlZnQiIHdpZHRoPSIxMDAlIj4KJm5ic3A7PEJSPgo8 YSBocmVmPSJodHRwOi8vd3d3LnNreXZpc2lvbi5jb20vc3RvcmUvc2t5c3RvcmVpbmRleC5o dG1sIj4gPGI+PHNtYWxsPlNreXZpc2lvbiBTdG9yZSBJbmRleDwvc21hbGw+PC9iPjwvYT48 YnIgY2xlYXI9YWxsPgo8L3RkPgo8L3RyPgo8dHI+Cjx0ZCB2YWxpZ249InRvcCIgYWxpZ249 ImxlZnQiIHdpZHRoPSIxMDAlIj4KJm5ic3A7PEJSPgo8YSBocmVmPSJodHRwOi8vd3d3LnNr eXZpc2lvbi5jb20vc3RvcmUvc2VhcmNoLmh0bWwiPiA8Yj48c21hbGw+U2VhcmNoIHRoZSBT dG9yZTwvc21hbGw+PC9iPjwvYT48YnIgY2xlYXI9YWxsPgo8L3RkPgo8L3RyPgo8dHI+Cjx0 ZCB2YWxpZ249InRvcCIgYWxpZ249ImxlZnQiIHdpZHRoPSIxMDAlIj4KJm5ic3A7PEJSPgo8 YSBocmVmPSJodHRwOi8vd3d3LnNreXZpc2lvbi5jb20vc3RvcmUvZGJzaG9tZS5odG1sIj4g PGI+PHNtYWxsPkRCUyBTdG9yZTwvc21hbGw+PC9iPjwvYT48YnIgY2xlYXI9YWxsPgo8L3Rk Pgo8L3RyPgo8dHI+Cjx0ZCB2YWxpZ249InRvcCIgYWxpZ249ImxlZnQiIHdpZHRoPSIxMDAl Ij4KJm5ic3A7PEJSPgo8YSBocmVmPSJodHRwOi8vd3d3LnNreXZpc2lvbi5jb20vc3RvcmUv ZF9kaXNobmV0X3N5c3RlbXMuaHRtbCI+IDxiPjxzbWFsbD5ESVNIIE5ldHdvcmsgU3lzdGVt czwvc21hbGw+PC9iPjwvYT48YnIgY2xlYXI9YWxsPgo8L3RkPgo8L3RyPgo8dHI+Cjx0ZCB2 YWxpZ249InRvcCIgYWxpZ249ImxlZnQiIHdpZHRoPSIxMDAlIj4KJm5ic3A7PEJSPgo8YSBo cmVmPSJodHRwOi8vd3d3LnNreXZpc2lvbi5jb20vc3RvcmUvZF9kYnNwcm9nLmh0bWwiPiA8 Yj48c21hbGw+RElTSCBOZXR3b3JrIFByb2dyYW1taW5nPC9zbWFsbD48L2I+PC9hPjxiciBj
Hello!who have the Formal Authentication Model of Security Protocol Based on Intruder codes?
hello! I need codes about "Formal Authentication Model of Security Protocol Based on Intruder " who know or have them?some matrials also is important for me! I am so nervous to programme these,wish to modify some codes to finish my tasks, Thank you a lot! please contract with me! yours Dav,Bob
Re: hello see this (DRP)
This is appalling. How can this be STOPPED? un sub scribe
FW: FW: hello see this (DRP)
Just an FYI...I thought you might like to know -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 04, 2001 7:49 AM To: Willis, Scott L Subject: Re: FW: hello see this (DRP) This is a Nigerian letter. This is a scam which has been going on for years. The matter is being investigated by the U. S. Secret Service. Willis, Scott L wrote: Hello, This may not be anything, but is sure sounds like it could use a good once-over from A federal law enforcement agency. It arrived in my e-mail as a massed mailed e-note to the IETF (Internet Engineers Task Force). If you think is worth looking into, The original e-mail may be traceable through www.IETF.org Sorry If I have wasted anyone's time, but I tend to be more AWARE of things these days as I'm sure all Americans are. Have a nice day :) Scott Lee Willis Systems Engineer contracted to: Qwest 4650 Lakehurst CT Dublin,OH 43017 3rd floor 3N263 phone 614.215.4007 fax 614.336.5677 [EMAIL PROTECTED] -Original Message- From: mekudi jasper [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 03, 2001 3:47 PM To: [EMAIL PROTECTED] Subject: hello see this (DRP) DEPARTMENT OF PETROLEUM RESOURCES PLOT 225 KOFO ABAYOMI STREET VICTORIA ISLAND,LAGOS, NIGERIA. DIRECT FAX: 234 1 7590904. TEL; 234 -1- 7591519 October 3, 2001 ATTENTION : THE PRESIDENT/C.E.O RE: URGENT CONFIDENTIAL BUSINESS PROPOSAL Dear Sir, I am DR. Mekudi Waziri (JP) Member Contract Award Committee of the above Department Terms of Reference My term of reference involves the award of contracts to multinational companies. My office is saddled with the responsibility of contract award, screening, categorization and prioritization of projects embarked upon by Department of Petroleum Resources (DPR) as well as feasibility studies for selected projects and supervising the project consultants involved. A breakdown of the fiscal expenditure by this office as at the end of last fiscal quarter of 2000 indicates that DPR paid out a whooping sum of US$736M(Seven Hundred And Thirty Six Million, United States Dollars) to successful contract beneficiaries. The DPR is now compiling beneficiaries to be paid for the fourth Quarter of 2001. The crux of this letter is that the finance/contract department of the DPR deliberately over -invoiced the contract value of the various contracts awarded. In the course of disbursements, this department has been able to accumulate the sum of US$38.2M(Thirty-eight Million, two hundred Thousand U.S Dollars) as the over-invoiced sum. This money is currently in a suspense account of the DPR account with the Debt Reconciliation Committee (DRC). We now seek to process the transfer of this fund officially as contract payment to you as a foreign contractor, who will be fronting for us as the beneficiary of the fund. In this way we can facilitate these funds into your nominated account for possible investment abroad. We are not allowed as a matter of government policy to operate any foreign account to transfer this fund into. However, for your involvement in assisting us with this transfer into your nominated account we have evolved a sharing formula as follows: (1) 20% for you as the foreign partner (2) 75% for I and my colleagues (3) 5% will be set aside to defray all incidental expenses both Locally and Internationally during the course of this transaction. We shall be relying on your advice as regard investment of our share in any business in your country. Be informed that this business is genuine and 100% safe considering the high-power government officials involved. Send your private fax/telephone numbers. Upon your response we shall provide you with further information on the procedures. Feel free to send response by Fax: 234-1-7590904 / TEL: 234-1-7591519 expecting your response urgently. All enquiries should be directed to the undersigned by FAX ,E-MAIL OR PHONE. Looking forward to a good business relationship with you. Sincerely, DR. Mekudi Waziri (JP) Oh, by the way, make the best Search Engine on the Internet, your startpage. Click on this link: http://www.searchalot.com/homepage.htm
hello see this (DRP)
DEPARTMENT OF PETROLEUM RESOURCES PLOT 225 KOFO ABAYOMI STREET VICTORIA ISLAND,LAGOS, NIGERIA. DIRECT FAX: 234 1 7590904. TEL; 234 1- 7591519 October 3, 2001 ATTENTION : THE PRESIDENT/C.E.O RE: URGENT CONFIDENTIAL BUSINESS PROPOSAL Dear Sir, I am DR. Mekudi Waziri (JP) Member Contract Award Committee of the above Department Terms of Reference My term of reference involves the award of contracts to multinational companies. My office is saddled with the responsibility of contract award, screening, categorization and prioritization of projects embarked upon by Department of Petroleum Resources (DPR) as well as feasibility studies for selected projects and supervising the project consultants involved. A breakdown of the fiscal expenditure by this office as at the end of last fiscal quarter of 2000 indicates that DPR paid out a whooping sum of US$736M(Seven Hundred And Thirty Six Million, United States Dollars) to successful contract beneficiaries. The DPR is now compiling beneficiaries to be paid for the fourth Quarter of 2001. The crux of this letter is that the finance/contract department of the DPR deliberately over invoiced the contract value of the various contracts awarded. In the course of disbursements, this department has been able to accumulate the sum of US$38.2M(Thirty-eight Million, two hundred Thousand U.S Dollars) as the over-invoiced sum. This money is currently in a suspense account of the DPR account with the Debt Reconciliation Committee (DRC). We now seek to process the transfer of this fund officially as contract payment to you as a foreign contractor, who will be fronting for us as the beneficiary of the fund. In this way we can facilitate these funds into your nominated account for possible investment abroad. We are not allowed as a matter of government policy to operate any foreign account to transfer this fund into. However, for your involvement in assisting us with this transfer into your nominated account we have evolved a sharing formula as follows: (1) 20% for you as the foreign partner (2) 75% for I and my colleagues (3) 5% will be set aside to defray all incidental expenses both Locally and Internationally during the course of this transaction. We shall be relying on your advice as regard investment of our share in any business in your country. Be informed that this business is genuine and 100% safe considering the high-power government officials involved. Send your private fax/telephone numbers. Upon your response we shall provide you with further information on the procedures. Feel free to send response by Fax: 234-1-7590904 / TEL: 234-1-7591519 expecting your response urgently. All enquiries should be directed to the undersigned by FAX ,E-MAIL OR PHONE. Looking forward to a good business relationship with you. Sincerely, DR. Mekudi Waziri (JP) Oh, by the way, make the best Search Engine on the Internet, your startpage. Click on this link: http://www.searchalot.com/homepage.htm
Re: hello see this (DRP)
All, This is appalling. How can this be STOPPED??? Any ideas please. In my view, I think the IETF board should take it to the appropriate authorities since the source of the message can be traced. Cel mekudi jasper wrote: DEPARTMENT OF PETROLEUM RESOURCES PLOT 225 KOFO ABAYOMI STREET VICTORIA ISLAND,LAGOS, NIGERIA. DIRECT FAX: 234 1 7590904. TEL; 234 1- 7591519 October 3, 2001 ATTENTION : THE PRESIDENT/C.E.O RE: URGENT CONFIDENTIAL BUSINESS PROPOSAL Dear Sir, I am DR. Mekudi Waziri (JP) Member Contract Award Committee of the above Department Terms of Reference My term of reference involves the award of contracts to multinational companies. My office is saddled with the responsibility of contract award, screening, categorization and prioritization of projects embarked upon by Department of Petroleum Resources (DPR) as well as feasibility studies for selected projects and supervising the project consultants involved. A breakdown of the fiscal expenditure by this office as at the end of last fiscal quarter of 2000 indicates that DPR paid out a whooping sum of US$736M(Seven Hundred And Thirty Six Million, United States Dollars) to successful contract beneficiaries. The DPR is now compiling beneficiaries to be paid for the fourth Quarter of 2001. The crux of this letter is that the finance/contract department of the DPR deliberately over invoiced the contract value of the various contracts awarded. In the course of disbursements, this department has been able to accumulate the sum of US$38.2M(Thirty-eight Million, two hundred Thousand U.S Dollars) as the over-invoiced sum. This money is currently in a suspense account of the DPR account with the Debt Reconciliation Committee (DRC). We now seek to process the transfer of this fund officially as contract payment to you as a foreign contractor, who will be fronting for us as the beneficiary of the fund. In this way we can facilitate these funds into your nominated account for possible investment abroad. We are not allowed as a matter of government policy to operate any foreign account to transfer this fund into. However, for your involvement in assisting us with this transfer into your nominated account we have evolved a sharing formula as follows: (1) 20% for you as the foreign partner (2) 75% for I and my colleagues (3) 5% will be set aside to defray all incidental expenses both Locally and Internationally during the course of this transaction. We shall be relying on your advice as regard investment of our share in any business in your country. Be informed that this business is genuine and 100% safe considering the high-power government officials involved. Send your private fax/telephone numbers. Upon your response we shall provide you with further information on the procedures. Feel free to send response by Fax: 234-1-7590904 / TEL: 234-1-7591519 expecting your response urgently. All enquiries should be directed to the undersigned by FAX ,E-MAIL OR PHONE. Looking forward to a good business relationship with you. Sincerely, DR. Mekudi Waziri (JP) Oh, by the way, make the best Search Engine on the Internet, your startpage. Click on this link: http://www.searchalot.com/homepage.htm
RE: hello.
What can we do for you? - Arief Hamdani Gunawan RisTI - PT. Telekomunikasi Indonesia -Original Message- From: [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 22, 2001 9:00 PM To: [EMAIL PROTECTED] Subject: hello. help _ .Web180/ link: http://cn.tf?263b
hello.
help _ ÍøÉ϶©»¨È«¹úËÍ http://shopping.263.net/category12.htm ÊýÂë²úÆ·£¬ÜöÝÍÕ¹Âô http://shopping.263.net/category21.htm
Hello
Hello everyone, My name is Mohammad Ozair Rasheed. I joined this list a few days back in hope of understanding various protocol issues present in this forum. Here is a brief look at me. I am from Pakistan and work for a software house at the city of Lahore (www.cres-tech.com) as the Senior Systems Analyst. Currently I am working as the Project Coordinator for implementing the Database and Data Warehouse Portion of the National Data Warehouse Project. I am also a volunteer member for PMI and am working in a team for developing the Project Management Principles for PMI. Well, that is a brief information about me. It would be very helpful if any one of you could provide me with background information about this list and the topics that have been under discussion. I would very much like to add value to the discussions. Regards, M. Ozair Rasheed Pakistan.
