הרשמה לניוזלטר

    כל השדות הם חובה למילוי

    שירותי קצה עם חיבוריות פתוחה – OPES

    הגדרה

    שירותי קצה עם חיבוריות פתוחה (Open Pluggable Edge Services- OPES) הנם שירותים המוטמעים במתווכים ברמת היישום, הנמצאים ברשת האינטרנט. שירות כזה יוכל להיות מצוי, לדוגמא, בזכרון מטמון היושב בשרת פרוקסי, הנמצא בין שרת המקור ללקוח.

    מטרתו, לסנן או לשנות מידע העובר דרכו. דוגמאות של שירותי OPES כוללות בין השאר הרכבת דפי אינטרנט מותאמים אישית, סריקת וירוסים, התאמת תוכן ללקוחות עם רוחב פס מוגבל, תרגום משפה לשפה והתאמה של מידע אזורי בדפי אינטרנט ללקוח.

    רקע

    השאלה של הצעת OPES התעוררה ב- IETF (קבוצת המשימה של הנדסת האינטרנט -Internet Engineering Task Force) והמחלוקת בקבוצת העבודה העוסקת בנושא העלו סוגיות בנושא ארכיטקטורה ומדיניות הנוגעות לחסינות ואמינות מקצה לקצה של מידע. דעה אחת שהובעה בקבוצה הייתה ש"הטכנולוגיה מלאה ברשעות ושהקבוצה צריכה לשמור מרחק כמה שיותר מההצעה הנתעבת הזו". אחרים חששו ש"הטכנולוגיה תפחית את האמינות ואת תחושת האמינות של תקשורת באינטרנט. בנוסף, הטכנולוגיה תעלה משמעותית את חוסר הוודאות לגבי מה שיכול היה להיעשות למידע במעברו ברשת" ולכן, לדעתם, הסיכונים של הטכנולוגיה גוברים על התועלות האפשריות.

    סוגיות טכניות

    באופן טבעי השאלה הראשונה תהיה האם ישנם יתרונות ארכיטקטוניים בהשמת שירותים מסויימים ברשת (לדוגמא ברמת היישום של זכרון מטמון בשרת פרוקסי), במקום בהשמתם אצל ספק התכנים או משתמש הקצה? נראה בבירור שאכן יכולים להיות יתרונות ארכיטקטוניים משמעותיים בהשמת שירותי OPES במתווך ברמת היישום הנמצא ברשת. לדוגמא, אם תוכן מסויים נמצא כבר בזכרון המטמון המקומי או האזורי, ונדרש שינוי במידע עבור משתמש הקצה (כגון התאמה לנתיב בעל רוחב פס מוגבל), אספקת שירותים ברמת המטמון עצמו יכולה למנוע בזבוז רוחב פס בשליפת המידע שוב מהספק, ובו בזמן מונעת עיכובים מיותרים בשירות למשתמש הקצה.

    שאלות נוספות מתייחסות לסוגייה האם היתרונות של אספקת שירותים ברשת עולות על המחיר הפוטנציאלי באמינות המידע, והאם יש לשירות, המתוכנן בעיקר לפעולה בודדת של שליפת מידע, השפעה על שכבת היישום המתייחסת לארכיטקטורה. OPES העלה מספר שאלות חשובות הנוגעות לאמינות, פרטיות, ואבטחה. בפרט, נראה שבלתי נמנע שבזמן כלשהו בעתיד חלק משירותי OPES יפעלו שלא כשורה (לדוגמא, סורק וירוסים החוסם מידע שאינו מכיל וירוס), וחלק ממתווכי OPES יפגעו בשגגה או בזדון. לאור זאת, נראה שחיוני לתת מענה לסוגיות אלו בארכיטקטורה הכללית של OPES מתחילת תהליך העיצוב של השירות. כמו כן, יש לתת כלים שעוזרים לשמור על אמינות מקצה לקצה של המידע ועוזרים לשרתים לאתר ולהגיב להתנהגות בלתי הולמת של מתווכי OPES. אחת מהמטרות של הארכיטקטורה של OPES חייבת להיות שמירה על העמידות, שהיא אחת ממטרות היסוד של ארכיטקטורת האינטרנט. לאור זאת הומלץ שה- IESG ( Internet Engineering Steering Group) ידרוש שהארכיטקטורה של OPES תגן על אמינות מידע מקצה לקצה על ידי תמיכה בזיהוי ותגובה להתנהגות לא הולמת של מתווכי OPES על ידי שרתי קצה.

    אחת הדרישות לכך ש-OPES יהיה חלק מהתקינה של ה-IETF הינה "הסכמת צד אחד", כלומר, אישור מפורש של לפחות שרת קצה אחד את ה-OPES. למרות זאת, מודל הסכמת צד אחד, כשלעצמו אינו מספיק לאבטחת אמינות המידע ברשת. אנחנו מסכימים שללא קשר למנגנוני האבטחה והאישור, שיתוקננו על ידי ה-IETF עבור ה-OPES, ניתן יהיה לעקוף מנגנונים אלו , דבר שיגרום לשינויים לא מאושרים בתוכן. עם זאת, מדובר בבעיה בבעיה אשר תקפה לפרוטוקולים רבים הנשקלים על ידי ה-IETF, וכשלעצמה אינה מייצגת סיבה מספקת לא לתקנן פרוטוקולי משלוח, פרוטוקלי ניתוב, פרוטוקולים של זכרון מטמון לרשת או את OPES עצמו. במקום זאת, התשתית עצמה צריכה להיות מתוכננת כך שתהיה מסוגלת לזהות ולהגן על עצמה מפני יישומים פגועים במידת האפשר. שימוש לא ראוי בפרוטוקל צריך להיות מטופל בצורה ישירה, במקום ההתרחשות.

    מנגנונים כגון חתימות דיגטליות, העוזרים למשתמשים לוודא בעצמם שתוכן לא שונה, הנם צעד ראשון בזיהוי שינויים לא מורשים בתוכן הנמצא ברשת. עם זאת, במקרה של OPES, הגנה נוספת לאבטחת אמינות מקצה לקצה של מידע הנה דבר רצוי. לדוגמא, בעזרה למשתמשי קצה בזיהוי מקרים שבהם מתווכי OPES מורשים עורכים שינויים לא מורשים בתוכן.

    אם OPES יוצע, קבוצת העבודה של OPES תצטרך להחליט ולתעד בצורה מפורשת האם OPES יהיה תואם עם השימוש בהצפנה באחד או יותר מהמשתתפים בהתקשרות מעורבת OPES. אם OPES יתמוך בהצפנה, יהיה אפשר להבטיח ביעילות שהתקשרות OPES ספציפית תוגבל למחשבים ידועים, בפנייה ישירה בשכבת ה-IP, והמורשים (באמצעות מפתחות הצפנה) לפחות באחד הצדדים המעורבים. בנוסף, תאימות עם הצפנה תמנע הטמעה של מערכת שירותים נוספת, שכדי ליהנות ממנה, נאלצים להשאיר את תוכן מנות המידע (packets) בצורה גלויה לכל, וזמינה למעקב.

    עמדת ISOC

    IAB המועצה המייעצת לארכיטקטורת האינטרנט (Internet Architecture Board) קבעה את ההמלצות הבאות אודות הצעת OPES ב-IETF :

    מסגרת OPES פתוחה המתוקנת על ידי ה-IETF חייבת לדרוש ששימוש בשירות כלשהו של OPES יהיה כרוך בהסכמה מפורשת של אחד הצדדים (ספק התוכן או הלקוח).

    במסגרת OPES המתוקנת על ידי ה-IETF, מתווך ה-OPES חייב להיות נגיש בצורה ישירה בשכבת ה-IP על ידי משתמש הקצה. מסגרת OPES הכללית חייבת לסייע לספקי תוכן בזיהוי ותגובה לפעולות מוכוונות משתמש שנעשות על ידי מתווך ה-OPES, ושספקי התוכן סוברים כי הן אינן ראויות. מסגרת OPES הכללית חייבת לסייע למשתמש הקצה לגלות התנהגות מתווכי OPES, תוך נתינת אפשרות לזיהוי מתווכי OPES לא ראויים או פגועים. אם קיימת גרסה "ללא OPES" של התוכן, אסור שארכיטקטורת ה-OPES תמנע ממשתמשים אפשרות לשלוף גרסה זו של התוכן מהספק. תיעוד OPES צריך להיות ברור בלתאר את שירותי OPES כמופעלים כתוצאה של זיהוי הכתובת (URI resolution) , ולא כחלק מפעולת הזיהוי עצמה. כל השירותים המוצעים חייבים להגדיר את ההשפעה על תקפות מראי מקומות והתייחסות בתוך ובין מסמכים. מסגרת OPES הכללית חייבת לספק מנגנונים שיאפשרו למשתמשי קצה לקבוע את מדיניות הפרטיות של מתווכי OPES.

    אודות

    Sally Floyd is a senior scientist at ACIRI, the AT&T Center for Internet Research at ICSI. Her research interests include congestion control in computer networks and the analysis of network dynamics. Among other activities, she is a member of the Internet Architecture Board.

    Leslie Daigle is Director of Directory Research at VeriSign. Her primary area of focus is in Internet applications infrastructure, particularly naming and directories. This paper is a condensed version of an IETF document edited by the authors

    The ISOC (www.isoc.org) Member Briefing series is made possible through the generous assistance of ISOC's Platinum Program Sponsors: APNIC, ARIN, Cisco Systems, IBM, Microsoft, Nortel Networks, Ripe NCC, and Softcomca.com.