[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SA bundles, multiple tunnels?

At 10:38 PM 12/1/98 +0200, you wrote:
>Hi folks,
>
>I'm currently involved in IPSec implementation, and
>I have a couple of specific questions. I've read the
>architecture draft several times by now, but it didn't
>seem to give me definitive answers.
>
>Question 1:
>
>Can one SA be a part of more than one SA bundle?
>
Yes, SA can be part of more than one SA bundle, if you allow sharing of SAs.

>Question 2:
>
><-------SA1---------------->
>          <-------SA2------>
>[IP1][AH][IP2][AH][IP3][TCP]
>
>Assume that I have two tunnel mode AH SAs. Both
>of these SAs terminate at the current router. I further
>define for both SAs a selector for "Transport Layer
>Protocol". What should they match? Will the selector 
>for SA1 match "IP" or will it go further down the
>headers all the way to "TCP"?

In the inbound IPSec Processing, all the SAs applied will be collected in a
SA Bundle, the selectors of the last SA applied will be compared with the
pkt selectors. Since the selectors wont change from one SA to the other SA
for one SABundle. Thus the transport protocol will be TCP while matching
the selectors.
>
>Question 3:
>
><-------SA--------->
>[IP1][ESP][IP2][TCP]
>
>This is a sort of stupid question. Assume that I have 
>one ESP SA terminating at the current router. Here a
>selector for transport layer protocol is also defined
>for this SA. Should the behaviour be to
>
>a) First match the selector, producing OPAQUE, since
>   the inner packet is still encrypted. Or
>
>b) First decrypt the packet, and only then match 
>   the selector, which now succeeds fine.
>
>Only b) seems sane, but the architecture RFC section
>5.2.1 only says 
>   "Use the SA found in (1) to do the IPsec processing, e.g.,
>    authenticate and decrypt.  This step includes matching the
>    packet's (Inner Header if tunneled) selectors to the
>    selectors in the SA."
>This could mean either behaviour.

 b) is the correct processing, selector comparison is done as said above. 
>
>Question 4:
>
>What sort of policy filtering does IPSec intend to define
>for throughgoing IPSec traffic? 
>
>This is related to the previous question, since if a) 
>is the intended behaviour, the following sentence at 
>section 4.4.2 makes a whole lot more sense.
>"NOTE: To locate the transport protocol, a system has to chain
>       through the packet headers checking the "Protocol" or "Next
>       Header" field until it encounters either one it recognizes as a
>       transport protocol, or until it reaches one that isn't on its
>       list of extension headers, or until it encounters an ESP header
>       that renders the transport protocol opaque."
>Thus for throughgoing traffic, which can't be authenticated
>or decrypted, the selector in the policy database would 
>go inside the protected packet.
>
During inboundprocessing, if the secprotocol extracted from the packet is
neither AH nor ESP then the inbound policies shold be searched for a
matching policy, which will lead to a bypass policy (if one present!). 

Hope this will help .

-Rohit
Follow-Ups: References: