„Проектиране на корпоративна vpn мрежа
Изтегляне 2.17 Mb.
|
| Дефиниция на ESP хедър
Положението на ESP хедъра е непосредствено след IP хедъра и опциите без значение от режима на работа на VPN. Номерът на протокола в IP хедъра е 50, тъй като ESP е дефиниран като протокол 50 от Асоциацията за присвояване на имена в Интернет (IANA). Както е показано на фигурата ESP хедърът съдържа няколко полета за създаване и поддържане на SA. ESP хедър Полето „SPI” е първата 32-битова стойност в хедъра. Стойностите от 1 до 255 са запазени, а нула се използва само при договаряне в ISAKMP на SA. Следващото поле се нарича “Sequence Number Field” (пореден номер) и се използва за защита срещу повторни атаки (replay) и за удостоверяване на източника. Ако защитата срещу повторни атаки е активирана, поредният номер трябва да бъде уникален за времето на действие на SA. Ако номерът достигне максималната стойност, SA се изтрива и се установява нова SA. “Payload data” е поле с променлива дължина, което е свързано с размера на данните, предавани от по-горните мрежови слоеве. Различни криптиращи алгоритми се използват за инициализиране на декриптиращия процес. В случай че конкретният криптиращ алгоритъм изисква инициализиращ вектор (initialization vector-IV), той се вмъква пред данните. “Padding” осигурява ограничена поверителност на комуникационния поток, но това е повече вторичен продукт от други изисквания, свързани с криптирането. Някои криптиращи алгоритми изискват оригиналните данни да съответстват на размера на блока, използван от алгоритъма.Padding се използва и за да гарантира, че дължината на pad и следващите полета на хедъра са дясно подравнени към 4-байтовата граница. Полето “Pad Length” е стойност, която дава на получателя информация относно дължината или броя на padding, които са добавени към шифрования текст. Padding е помощно поле, но използването му не е задължително. Полето “Pad Length” обаче трябва да съществува, дори когато не се използва pad. Полето “Next Header” е 8-битово поле, което показва типа от данни, съдържащи се в полето Payload data. То е необходимо за декриптирането на данните, което да позволи те да бъдат обработени правилно. “Authentication Data” е поле с променлива дължина, което съдържа Integrity Check Value (ICV), изчислена от ESP пакета без Authentication Data. Дължината му се определя от избраната удостоверителна функция. Полето Authentication Data не е задължително и се включва, само когато по време на осъществяване на SA е избрана удостоверителната услуга. За правилното прилагане на ESP са необходими няколко последователни стъпки. Процедурите са пряко свързани с посоката на данните: предаване или приемане. Процес на предаване Съществува последователност от пет стъпки, които са необходими за прилагането на ESP. Те предполагат, че са използвани поверителност и удостоверяване. 1. Енкапсулиране на горния слой данни в полето Payload. В транспортен режим това се прилага само за горния слой протоколи, а ако комуникацията е в тунелен режим – за горния слой и оригиналния IP хедър. 2. Добавяне на необходимия padding. Попълване на полетата Pad Length и Next Header. 3. Криптиране на данните, което включва горния слой, pad, pad length и next header. Ако криптиращият алгоритъм изисква инициализиращ вектор (IV), такъв се създава и прилага в съответствие с използвания криптиращ стандарт. 4. Създаване на ESP хедър. Вмъкване на пореден номер. Ако това е първият пакет, му се присвоява стойност единица. 5. След завършване на криптирането, удостоверяването се прилага към информацията в ESP хедъра (SPI и Sequence number) и Payload, което включва данните от горния слой, информацията от padding и полето Next Header. Полученият резултат се добавя в края на пакета след шифрования текст. Процес на приемане Ако по време на пренасянето възникне фрагментация, преди обработването на ESP се осъществява дефрагментация. След нейното приключване се извършват няколко стъпки: 1. Използване на полето SPI в ESP хедъра и IP адреса на получателя с цел намиране на SA в базата данни SA. Ако този процес се окаже неуспешен, пакетът се отхвърля. 2. Проверка на поредния номер, в случай че е активирана защита срещу повторни атаки. 3. Използване на SA, установена в предходния етап, за удостоверяване и декриптиране на данните в ESP. 4. След декриптирането - използване на вътрешния IP хедър за определяне на селектор в SA. 5. Намиране на стойност в SPD , която съвпада с данните от вътрешния пакет с цел установяване валидността на пакета за съответната SA. 6. Препращане на данните към крайната точка въз основа на информация от вътрешния IP хедър. Удостоверяване на ESP и защита срещу “replay” атаки В IPSec протокола съществуват механизми за защита от атаки, които се основават на събирането на данни и повторното им връщане в по-късен етап. Поредните номера в хедърите на протоколите за сигурност са предназначени да осигуряват защита срещу повторни атаки. Този, който изпраща пакета, попълва и управлява поредния номер, а получателят следи за неговата проверка. Според стандарта RFC (RFC2406) защитата срещу повторни атаки може да бъде активирана, само ако е избрано удостоверяване на източника на данните и това е предоставено на преценката на получателя. Ако ESP е имплементиран без удостоверяване и е приложена защита срещу повторни атаки, “поредният номер” не е удостоверен. В противен случай поредният номер се включва в полето authentication payload. Ако някой прихване пакет и направи опит да промени поредния номер при използвано удостоверяване, получателят ще открие промяната и ще отхвърли дейтаграмата. Почти всички имплементации поддържат ESP без удостоверяване, тъй като това е позволено в RFC. Неизползването на удостоверяване в ESP обаче разкрива няколко уязвимости, поради което строго се препоръчва неговото прилагане. Изтегляне 2.17 Mb. Сподели с приятели:
|