Subject: Re: [Ipsec] Next Layer Protocol (Ref: 2401-bis draft)

From: Stephen Kent <[email-masked]>
Date: Thu, 7 Apr 2005 11:12:59 -0400

At 6:33 PM -0800 3/17/05, Subha Venkataramanan wrote:
>Hi ,
>
>I have a follow-up question.
>
>If an implementation understands says hop-to-hop,
>routing, fragmentation and Destination Options, it
>can parse these extension headers and look for the
>next protocol information. When it parses each
>extension header, it knows the length of bytes it
>needs to skip to reach the next extension header.
>
>If there are any new extension headers and the
>implemenation cannot interpret these extension
>headers, it cannot process the packet. In which
>case, it may choose to send an ICMP Error message.
>
>What additional help is given to the implementation,
>by configuring the extension headers that it needs
>to ignore while parsing the IPv6 header.

this is a feature designed to help support IPsec, in the IPv6 
context. after inbound processing, IPsec access controls are applied 
based on the SAD entry for the SA via which the traffic arrived. thus 
it is important to know what constitutes the "next layer protocol" to 
which these access controls are to be applied. The use of a list 
enables a receiver to accommodate new IPv6 headers in the future. The 
list is configured with default entries for the header types that are 
defined now and that make sense to skip. similarly, for outbound 
processing, this list indicates where to look to find the protocol 
that is used for outbound access control, SA selection. This is 
mostly an AH issue, because there is more flexibility in where AH can 
be placed relative to IPv6 headers, vs. ESP.

>1) Does this kind of configuration in the
>implementation advise the user, that it has
>capabilities skip A,B,C extension headers ?

that is a local implementation issue, not dictated by the standards, 
but I would expect this info to be viewable as part of the 
configuration data.

>2) Does this kind of configuration mean, that if the
>implementation comes across any other extension
>headers which it can interpret but is not in the
>configured list, it should drop the packet ?

As soon as one encounters a header that is not on the list, then that 
header is the one that will be examined against the SAD entry. if 
there is an extension header present that is not on the skip list, 
and it is not the one you listed in the SPD (and now in the SAD entry 
for the SA), then the packet will be dropped.

>3) Does this kind of configuration mean, that when the
>user tries to add some extension header values, that
>the implementation does not support, it can throw an
>error indicating the same ?

If you add a header not on the list, AND if the intent was to skip 
the header, then the packet will be dropped.

Steve

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec