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

Re: SA bundles, multiple tunnels?



rohit@trinc.com wrote:
> >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.

OK. I hadn't looked at ISAKMP / IPSEC DOI stuff yet, but after I 
did that I can understand what you mean. I.e. you can negotiate
the SA bundle == SA payload as follows. Since you can specify the
SPI value in this negotiation, the answer was "yes". (Q.E.D. ;-)

SA Payload
                Proposal payload / SPI
                                        Transform payload
                AND
                Proposal payload / SPI
                                        Transform payload OR
                                        Transform payload
           OR 
                Proposal payload / SPI
                                        Transform payload OR
                                        Transform payload

> >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.

It seems I read the architecture draft somewhat incorrectly. Would
the following be correct?

An SPD entry defines a set of selectors. When a corresponding
SAD entry is created, the selectors are either given the value
inside the packet or inside the SPD entry (instantiated).
The instantiated selectors are associated with the SA bundle
in the SAD. A shared SA, i.e. one that appears in several 
SA bundles, could be associated with several sets of instantiated
selectors, with one set in each bundle.

> >
> >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.

Let's rephrase the question. Suppose I wish to define 
either of the following security policies. (Of course
the firewall couldn't actually check authentication.)

[IP1][AH][IP2][TCP]
"all throughgoing TCP traffic to port
X must be authenticated in tunnel mode". 

[IP1][AH][TCP]
"all throughgoing TCP traffic to port
X must be authenticated in transport mode". 

Would I be able to use the transport layer protocol and
destination port selectors in the SPD to give
these sorts of traffic a bypass policy? Would I need
additional implementation dependant selectors?

> Hope this will help .
> 
> -Rohit

Sure. Thanks.

///Ari
begin:vcard 
n:Huttunen;Ari
tel;fax:+358-9-2992634
tel;work:+358-9-2992472
x-mozilla-html:FALSE
org:L M Ericsson;LMF/T/TK
version:2.1
email;internet:Ari.Huttunen@lmf.ericsson.se
title:Software Designer
adr;quoted-printable:;;Oy L M Ericsson Ab=0D=0ATelecom R&D;;;02420 Jorvas;Finland
x-mozilla-cpt:;-30024
fn:Ari Huttunen
end:vcard

References: