یکی از اسلایدهای جالبی که هفته‌ی قبل در IETF99 پراگ دیدم؛
بقول یکی از شرکت‌کننده‌ها: "اینترنت از کلی تونل ساخته شده"
ارائه در Transport Working Group
📡 @networkz

شاید یکی از اصطلاحاتی که این روزا راجع بهش زیاد می شنویم و مطلب می بینیم تو دنیای شبکه، SDN یا همون Software Defined Networking هست.

اما این تکنولوژی چیه؟ از کجا ایده ی شکل گیریش مطرح شده؟ مهم ترین هدفش چی هست؟ مکانیزم عملکردش به چه صورت هست؟ چه حوزه هایی رو تحت تاثیر قرار میده؟

در این ویدیوی کوتاه سعی شده تا با معرفی اجمالی SDN به این سوالات پاسخ داده بشه.

📡 @networkz

👇👇👇
http://www.computerworld.com/video/79155/what-is-software-defined-networking-sdn

داستان Troubleshooting مشکلِ دانلود در دنیای واقعی!
اگر به اینکه TCP چطور کار می‌کنه و چجوری با packet capture میشه برخی مشکلات رو پیدا کرد، علاقمند هستین پس لینک زیر رو بخونین
📡 @networkz

https://www.snellman.net/blog/archive/2017-07-20-s3-mystery/

در تاریخ 14 جولای 2017، نهاد IETF با انتشار RFC 8200 رسما اعلام کرد که IPv6، آخرین نسخه ی استاندارد IP هست.

البته باید اذعان کرد که اولین بار IPv6 در RFC 2460 و حدود 18 سال پیش معرفی شده بود اما این RFC صرفا یک Draft Standard بود ولی RFC 8200 برخلاف اون یک، Internet Standard هست.


اما مگه تفاوت این دو تا چی هست که انقد مهمه؟ برای دونستن تفاوت بین Draft Standard و Internet Standard باید مروری بر فرآیند استاندارد سازی فایل ها در IETF داشته باشیم، قضیه از این قرار هست که:

بر طبق RFC 2026، همه چیز با یک Internet Draft آغاز میشه. Internet Draft ها فایل هایی هستن که حاوی ایده های خام و اولیه در رابطه با یک موضوعن و هنوز روی این موضوع ها داره کار میشه. عمر اون ها هم معمولا 6 ماه هست و بعد شیش ماه منقضی میشن یا این که به روزرسانی میشن.

ممکنه یک ID توسط یک Working Group به تصویب برسه اما برای این که برسه به فاز بازبینی و تبدیل شدن به یک Request for Comment یا RFC باید انقد تغییر و اصلاح بشه تا سر تصویب اون موضوع یک توافق عام کسب بشه.

بر اساس اون چیزی که در RFC 2026 مشخص شده، موضوعات برای این که بتونن به Internet Standard یا به بیان دیگه Standards Track تبدیل بشن، اول در یکی از سه دسته ی زیر قرار می گرفتن:

1- Proposed Standard:
موضوعاتی که در این گروه قرار میگیرن، خوب تونستن توجیه، درک و فهمیده بشن، مورد توجه و بازبینی قابل توجهی هم از طرف نهادها قرار گرفتن اما هنوز نیازمند پیاده سازی و تجربیات عملی هستن و ممکنه بعد از کسب این تجربیات، تغییر کنن.

2- Draft Standard:
موضوعاتی هستن که تقریبا به مرحله ی پیاده سازی رسیدن و تونستن تجربیات موفقیت آمیز خوبی هم به دست بیارن اما باید بیشتر روی توسعه و پیاده سازی های اون ها کار بشه تا ثباتشون کاملا مشخص بشه.

3- Internet Standard:
موضوعاتی که در این دسته قرار میگیرن دیگه از همه جهت تونستن پیاده سازی و تجربیات عملیاتی موفقیت آمیزی رو کسب کنن و کاملا مورد تایید community قرار بگیرن. به موضوعاتی که در این دسته قرار بگیرن شماره ای تحت عنوان SID اختصاص پیدا می کنه.

در سال 2011 در RFC 6410 که در واقع نسخه ی آپدیت شده ی RFC 2026 هست، دسته بندی بالا به دو دسته ی Proposed و Internet Standard تبدیل شد و Draft Standard حذف شد بنابراین موضوعاتی که در دسته ی Draft Standard قرار میگرفتن، یکی از این دو عمل زیر در قبالشون انجام گرفت:

1- اگر در رابطه با یک draft standard هیچ errata یا غلطنامه ای وجود نداشته باشه که نیازمند یک پیاده سازی جدید باشه، اون draft standard به دسته ی Internet Standard منتقل میشه.
2- خود IESG تصمیم بگیره که یک Draft Standard در دسته ی Proposed قرار بگیره.

اتفاقی که برای IPv6 افتاد، مورد اول از موارد بالا بود. یعنی کارگروه 6MAN یا همون IPv6 Maintenance (6MAN) Working Group از سال 2015 تلاش کرد که تمام RFC ها (9 مورد) و همینطور Errata ها (2 مورد) در رابطه با IPv6 رو مورد بازبینی و تجدید نظر قرار بده و کل اون ها رو در قالب RFC 8200 معرفی کنه. در واقع این RFC شامل مفاهیم مطرح شده در RFC 2460 به همراه تمام RFC ها و Errata های مرتبط با IPv6 هست و تغییر چندانی رو شامل نمیشه.

اما اگر دقیق تر میخواید بدونید که چه مباحثی در RFC 8200 مطرح شدن که نسبت به RFC 2460 تغییر کردن، آقای راس وایت لطف کردن و در پست زیر این تغییرات رو توضیح دادن:


📡 @networkz

👇👇👇
http://www.circleid.com/posts/20170726_look_at_rfc8200_which_officially_made_ipv6_an_internet_standard/

اگر براتون سواله سراغ کدوم سیستم‌عامل لینوکسی برین، این دیاگرام دیدِ خوبی میده

📡 @networkz

https://twitter.com/moghaddas_it/status/892025106993754112

📝 از زمانی که احساس شد مسیریابی صرفا بر اساس مقصد همیشه خوب و دلخواه نیست، ایده ی تعیین شرایط مسیریابی در مبدا متولد گشت و برای تحقق این ایده، مدام راهکارهای مختلفی مطرح شد: از PBR تا رفتن به سمت MPLS و سپس پیشرفت آن به MPLS-TE و نهایتا معرفی روشی با نام Segment Routing.

به این ترتیب تعیین شرایط مسیریابی در مبدا یا به عبارت بهتر، انجام Source Routing که روزی تنها در حد یک ایده بود، روز به روز به یک واقعیت و منطق جدید در مسیریابی نزدیکتر شد. آنچه سبب شده تا ایده ی Source Routing بیشتر به واقعیت نزدیک شود، راهکار Segment Routing می باشد. برای درک بهتر عملکرد Segment Routing ابتدا بهتر است مروری بر عملکرد MPLS و MPLS-TE داشته باشیم.


📡 @networkz

👇👇👇
https://fa.ip.engineering/mpls-mpls-te

خانه🏠 و آپارتمان🏢
#VM #Container #Docker

📡 @networkz

https://twitter.com/moghaddas_it/status/894175404621262848

📝 در RFC های BGP که تا الان منتشر شدن، هیچ اشاره ی مستقیمی نشده به این که "رفتار پیش‌فرض همسایه‌های eBGP در تبادل روت‌ها وقتی هیچ Policy خاصی اعمال نشده" چطور باشه، و این باعث می شد که هر وِندوری رفتار سلیقه ای خودش رو در این مورد داشته باشه. همین موضوع باعث به وجود اومدن مشکلاتی مثل ترانزیت شدن ناخواسته ی یک AS بین AS های دیگه می شد.

حدود یک ماه قبل با انتشار RFC8212 در Standards Track تمامی وندورها ملزم شدن که رفتار پیش‌فرض در همسایگی eBGP را به “عدم ارسال هیچ روتی” تغییر بدن.

در این مقاله قصد داریم تا بیشتر با جزییات و اهمیت RFC 8212 آشنا بشیم.

📡 @networkz

👇👇👇
https://fa.ip.engineering/تغییر-رفتار-پیش‌فرض-ebgp-با-rfc8212

مهاجرت به IPv6: راهکار NAT64

📡 @networkz

👇
https://fa.ip.engineering/مهاجرت-به-ipv6-nat64

در تاریخ 25 آگوست 2017، برخی از کاربران اینترنت که بخش بزرگی از اون ها را کاربران ژاپنی تشکیل میدادند، در ارتباطات اینترنت خودشون شاهد کندی و در مواردی قطعی ارتباطات اینترنت میشن. گستردگی این اختلالات و قطعی ارتباطات در ژاپن به حدی می رسه که باعث میشه وزارت ارتباطات ژاپن پیگیر دلیل بروز این قطعی بشه.

در بررسی هایی که انجام میشه، مشخص میشه که گوگل prefix‌های که در بستر داخلی IXPها جهت peering استفاده می‌شدند رو announce می‌کرده خب این نشون دهنده ی این بوده که یه چیزی در تبلیغات BGP گوگل درست انجام نمی شده. اما علت چی بوده؟

گوگل یکی از بزرگترین CDN های دنیاست و از طرف دیگه مرجع حجم عظیمی از ترافیک وب سایت های مشهوری مثل یوتیوب، گوگل درایو و ... هست. در نتیجه خیلی از شبکه ها در حال تبادل حجم قابل توجهی از ترافیک خودشون فقط با گوگل هستن و به همین دلیل سعی می کنن تا با ترفندهای traffic engineering کاری بکنن که ترافیکشون از طریق لینک های ارتباطی درستی که با گوگل دارن، ارسال بشه.

یکی از این ترفندها، عدم تجمیع و تبلیغ prefix های more specific (یا همون prefix های خاص تر) هست. با این روش طول AS-Path یا local prefernces ای که گوگل تعیین میکنه دیگه مهم نیستن، همیشه prefix خاص تر ترجیح داده میشه.

در زمان رخ دادن این اختلالات، بررسی ها تعداد زیادی prefix های خاص؛ یعنی prefix هایی که در حالت عادی نباید در global internet routing table باشن و فقط به جهت رفع نیازهای مهندسی ترافیک بین گوگل و همسایگانش استفاده میشن؛ رو نشون میدن. مثلا prefix ای مثل 114.154.133.0/24 در حالت عادی نباید در اینترنت دیده بشه و باید در قالب یک آدرس تجمیع شده مثل 114.144.0.0/12 قرار بگیره که این آدرس هم از طریق AS4713 NTT OCN که بزرگترین سرویس پروایدر ژاپن هست تبلیغ میشه. اما در زمان بروز اختلالات مشاهده میشه که بیش از 20,000 از این prefix های خاص که در اصل باید در قالب آدرس های تجمیع شده می بودن (عمدتا /11 یا /12 یا /13 یا /14 یا 1/5)، به همین صورت در اینترنت از جانب OCN تبلیغ می شدن.

در واقع OCN از این Prefix های خاص به جهت کنترل ترافیکی که از جانب گوگل دریافت میکرده، استفاده میکرده و قرار نبوده این prefix ها وارد دنیای اینترنت بشن، اما گوگل این prefix ها رو برای Verizon تبلیغ می کنه و به این ترتیب این prefix ها وارد دنیای اینترنت شدن و چون این prefix ها خاص تر بودن، ترافیک های مربوط به این prefix ها به سمت گوگل و Verizon ارسال میشدن و به این ترتیب ترفند مهندسی ترافیک محلی OCN به یک راهکار مهندسی ترافیک جهانی تبدیل شده بوده! :))

شرحی که داده شد بخشی از مقاله ی زیر هست که با جزییات دقیق به بررسی این مساله پرداخته:

📡 @networkz

👇👇👇
https://bgpmon.net/bgp-leak-causing-internet-outages-in-japan-and-beyond/

برای اولین بار، ICANN در حال تغییر کلیدهای رمزنگاری به منظور کمک به امنیت DNS در دنیای اینترنت هست. بر طبق گفته ی دیوید کونراد، مدیر ارشد تکنولوژی ICANN، تمام ISP ها و اپراتورهای شبکه در سراسر دنیا باید اطمینان حاصل کنن که برای این تغییر آماده هستن. چون در غیر این صورت کاربرانشون دیگه قادر به انجام domain lookup نخواهند بود و در نتیجه به هیچ سایتی در اینترنت دسترسی نخواهند داشت.

هم چنین بر طبق گفته ی کنراد، اپراتورهای شبکه باید مطمئن بشن که نرم افزارهاشون از DNSSEC پشتیبانی می کنن و می تونن به صورت خودکار کلیدهاشون رو به روز رسانی کنن و یا اگر امکان به روز رسانی خودکار نیس، به صورت دستی این فرآیند رو باید در تاریخ 11 اکتبر انجام بدن.

تغییر یا اصطلاحا rolling کلیدها، گامی مهم در حفظ امنیت DNS در اینترنت محسوب میشه. بر طبق گفته ی کنراد، پلتفرم آزمایشی راه اندازی شده که اپراتورهای شبکه برای اطمینان از این که برای این تغییر کلید قبل از 11 اکتبر، آماده هستن می تونن به اون ( یعنی آدرس: https://go.icann.org/KSKtest) مراجعه کنن و این تست رو انجام بدن. از طرف دیگه کاربران اینترنت هم می تونن با ISP های خودشون تماس حاصل کنن و مطمئن بشن که برای این تغییر آمادگی دارن یا نه.

لازم به ذکر هست که ICANN با همکاران فنی خودش مثل Regional Internet Registries، Network Operations Groups و ... در ارتباط بوده تا مطمئن بشن که تمام کسانی که تحت تاثیر این تغییر قرار میگیرن، از اون آگاه باشن.

متن اصلی این خبر رو می تونید از طریق لینک زیر مطالعه کنید:

📡 @networkz

👇👇👇
http://www.domainpulse.com/2017/08/20/changing-keys-internets-addressing-system/

مکانیزم های مهاجرت به IPv6: راهکار 464XLAT

📡 @networkz

👇
https://fa.ip.engineering/مهاجرت-به-ipv6-464xlat

حملات DDoS روز به روز پیشرفته تر میشن و دیگه مثل سابق صرفا حجم عظیمی از ترافیک که به صورت ناگهانی به سمت ساختار شبکه فلود بشن، نیستن. تو همچین شرایطی دیتاسنترها معمولا از یکی از روش های DDoS mitigation یا شرکت هایی که این خدمات رو ارایه میکنن استفاده میکردن.

اما هکرها هم در این حین بیکار نموندن، اون ها هم روز به روز حملاتشون رو هوشمندانه تر از قبل کردن. به عنوان مثال در یک حمله ی application-base، تعدادی request برای اطلاعاتی که نیازمند منابع زیادی هستن به سمت اپلیکیشن ارسال میشه و کاری میکنه که اپلیکیشن از کار بیوفته. حجم این پیام ها میتونه انقد کم باشه که اصلا تصور نشه که یک حمله ی DDoS اتفاق افتاده.

به همین دلیل توصیه میشه که به جای استفاده از روش های قدیمی DDoS mitigation، از چند لایه ی حفاظتی در برابر حملات استفاده بشه. به عنوان مثال در روترهای لبه ی ساختار، جلوی حملات حجمی گرفته بشه و بعد از این که پیام ها از این لایه ی اول امنیتی عبور کردن، برای یک scrubbing server ارسال بشن تا ترافیک خوب از بد جدا بشه.

از طرف دیگه گاهی یک وب سایت یا یک دیتاسنتر مستقیما مورد حمله قرار نمی گیره و این حمله برای یک DNS server رخ میده. در همچین شرایطی پیشنهاد میشه از خدمات کلودی استفاده بشه که اون وندور از چندین DNS server مختلف بهره میگیره. اینطوری اگر یک DNS server مورد حمله واقع بشه، DNS server دیگه میتونه پکت ها رو به سمت کلود هدایت کنه.

متن بالا بخشی از مقاله ای هست که می تونید کاملش رو از طریق لینک زیر مطالعه کنید:

📡 @networkz

👇👇👇
http://www.datacenterknowledge.com/security/how-fight-new-breed-ddos-attacks-data-centers

ارتباطات در دنیای اینترنت بر مبنای پروتکل BGP هست به این معنی که روترهای Core در دنیای اینترنت برای هدایت ترافیک به مقاصد مختلف از BGP استفاده می کنن.

در اواخر دهه ی 1980 بود که BGP رسما منتشر شد و با استفاده از اون روترها می تونستن به تبادل اطلاعات با هم بپردازن و از میون تعداد بیشماری مسیر برای ارسال داده ها در دنیای اینترنت، بتونن بهترین مسیر رو انتخاب کنن. در اون زمان، امنیت یک مساله ی مهم و جدی به حساب نمیومد و مثل خیلی از پروتکل های دیگه ای که در اون زمان معرفی شدن و برای اون ها هیچ ملاحظات امینتی در نظر گرفته نمی شد، BGP هم از این قاعده مستثنی نبود.

اما با گذشت زمان کم کم مشکلات امنیتی پررنگ و پررنگ تر شدن. تا جایی که این روزها مدام خبرهایی از hijack مسیرها در دنیای اینترنت، مسیرهای انحرافی و ... به گوش می رسه. BGP که در حال حاضر در دنیای اینترنت گسترش یافته، در حقیقت هیچ مکانیسم دفاع داخلی نداره و علت بروز چنین حملات و آسیب پذیری هایی هم به همین دلیل هست.

اما مجموعه ای از استانداردها تحت عنوان Secure Inter-Domain Routing ( یا SIDR) توسط IETF منتشر شدن که نشون دهنده ی اولین تلاش ها برای دفاع از سیستم مسیریابی اینترنتی در برابر حملات هستن.

این مکانیسم دفاعی بر پایه ی روش های رمزنگاری هست تا این اطمینان حاصل بشه که داده ها فقط از مسیرهایی که براشون مجاز تعریف میشه، عبور کنن. سه بخش اصلی که IETF SIDR در حال کار بر روی اون ها هست عبارتند از:

1- Resource Public Key Infrastructure (RPKI)
که در واقع به دارندگان بلوک هایی از آدرس های اینترنتی مثل فراهم کنندگان خدمات ابری، این امکان رو میده که تعیین کنن چه شبکه هایی می تونن یک direct connection با آدرس های بلوکشون داشته باشن.

2- BGP Origin Validation
که به روترها این امکان رو میده که با استفاده از اطلاعات RPKI بتونن مسیرهای BGP تبلیغی که غیرمجاز هستن رو فیلتر بکنن و به این ترتیب جلوی حملاتی مثل hijack مسیرها گرفته بشه.

3- BGP Path Validation
که تحت عنوان BGPsec شناخته میشه و RFC مربوط به اون اخیرا توسط IETF منتشر شده، در واقع نوآوری جدیدی هست که این امکان رو برای روترها فراهم میکنه تا با استفاده از امضای دیجیتال مطمئن بشن که کل مسیردر دنیای اینترنت از شبکه های مجاز عبور کرده.

از طریق صفحه ی مربوط به SIDR (لینک زیر) در وب سایت IETF، می تونید این استانداردها، روند پیشرفتشون و آخرین تغییراتشون رو پیگیری کنید:

📡 @networkz

👇👇👇
https://datatracker.ietf.org/wg/sidr/documents/

خیلی اوقات هست که وقتی به خروجی traceroute نگاه می‌کنیم، بعد از هاپ اول یا دوم، delay بطرز ناگهانی خیلی افزایش پیدا می‌کنه اما پس از اون تا انتهای مسیر تقریباً یکسان می‌مونه.
خیلی دیده شده که شخصی که با اون بستر آشنایی نداشته گفته: «ببین، مشکل از لینک بین هاپ اول و دومه، چون ازونجا یکهو RTT رفته بالا»....
اما اغلب اوقات این افزایش قابل انتظار هست، چرا که یک مسیر MPLS بین مبدأ تا مقصد وجود داره.
مطلب زیر به خوبی و سادگی این مورد رو شرح داده

📡 @networkz

http://movingpackets.net/2017/10/06/misinterpreting-traceroute/

📡 @networkz

WPA2 vulnerability: just a small update!

مرگ دنیای وِب از ۲۰۱۴ شروع شد!
📡 @networkz
تقریباً ازون موقع همه‌چی همینطوری مونده، ظاهر صفحات، فیچرهای تحت وب و ... اما چیزی که خیلی تغییر کرده زیرساخت ها است.
از همه مهمتر نکته جالب و در عین حال ترسناک قضیه اینه که گوگل و فیسبوک بیش از ۷۰ درصد ترافیک دنیا رو کنترل می‌کنن.

مقاله زیر برمبنای یکسری تحقیقات و حقایق انجام شده و خوندنش خالی از لطف نیست.

https://staltz.com/the-web-began-dying-in-2014-heres-how.html

اگر این مقاله رو به خاطر داشته باشید، سعی کردیم تا در اون مشکلات امنیتی DNS رو با هم بررسی کنیم. سال ها DNS به عنوان یکی از بزرگترین و اصلی ترین سرویس های اینترنت، با مشکلات امنیتی مختلفی دست و پنجه نرم کرد و این در حالی بود که راه حل این مشکلات مدت ها قبل معرفی شده بود اما هیچوقت جدی در نظر گرفته نشده بود تا این که در سال های اخیر نیاز به پیاده سازی و گسترش این راهکار در جامعه ی اینترنت به صورت چشمگیری روز به روز بیشتر شد. این راهکار، پروتکلی بود تحت عنوان: *DNSSEC*.

به صورت خیلی خلاصه، DNSSEC با اضافه کردن امضای دیجیتال به رکوردهای DNS، یک دامنه نام امن ایجاد می کنه.
در این مقاله سعی داریم تا با هم، با مفاهیم و اصطلاحات جدیدی که به همراه DNSSEC معرفی می شن و همینطور نحوه ی عملکرد اون، بیشتر آشنا بشیم.

📡 @networkz

👇👇👇
https://fa.ip.engineering/dnssec-عملکرد

📣 به عنوان ادمین شبکه آشنایی داشتن با دستورات لینوکس یه امر ضروری هست. پس سعی کردیم تا فایلی از مهمترین این دستورات رو آماده و ارائه کنیم 👇

📡 @networkz
https://fa.ip.engineering/لینوکس-دستورات-ضروری

آیا همیشه اصطلاحا کشتن فرآیندها (kill processes) در هنگام تامین امنیت یک راهکار خوب محسوب میشه؟ تا حالا شده قبل از انجام کاری یا تعریف سیاستی یا فراهم آواردن خدمتی، دقیق کارتون رو بررسی کنید و ببینید که نتیجه ی حاصل از کار یا خدمتی که فراهم می کنید، بر چه بخش هایی ممکنه اثرگذار باشه و چه تاثیری بر اون ها میذاره و آیا این تاثیرات مثبت هستن یا منفی؟

📡 @networkz

اگر شما جز افرادی هستید که در حوزه ی امنیت فعالیت می کنید یا کلا فردی هستید که خدمتی رو برای دیگران فراهم می کنید که این خدمت شما بر بخش های مختلفی تاثیرگذار هست، خوندن این مطلب خالی از لطف نیست:

👇👇
https://lkml.org/lkml/2017/11/21/356

وقتی مدیر شبکه هستی و خیلی منطقی وظایف کاربرا و خودت رو در هنگام رخ دادن مشکل، براشون شرح میدی! 🙄😁

📡 @networkz