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

Re: using por numbers in selectors

Assume following scenario:

    H1------SG1------------------SG2------H2

H1 is sending packets to H2.
If SG1 is having policies based on IPaddress and Ports, then it will
reassemble packets coming from H1, apply security and forward the
packet. During this forwarding, based on MTU, this might also get
fragmented. If all of the SG1 policies are IP address based alone then
SG1 may not reassemble the packets coming from H1.

At SG2, before applying secruity, it will reassemble all fragmented
secured packets and IPSEC will be applied and the packet will be sent
to the final destination ie H2. Currently we do reassemble of decapsulated
packets before sending them to H2. I am not sure whether we really
require to do this. If SG1 support ports based policies, it would have
assembled all fragments before applying security. All of the secured fragments
are reassembled at SG2 before passing the packet through the security.
That means SG2 after security processing has full packet.
In case of SG1 not supporting port based policies, it will not fragment
the packets coming from H1. And at SG2, the fragments can be passed
to the H2 individually as IPSEC SA indicates only IP address identification.

I would like to know what other think.

Thanks
Srini


Volpe, Victor wrote:

> Isn't there an issue with port number policy lookups and fragmented packets?
>
> Victor
>
> > -----Original Message-----
> > From: Dan McDonald [mailto:danmcd@Eng.Sun.Com]
> > Sent: Tuesday, June 22, 1999 6:46 PM
> > To: bkavsan@ire-ma.com
> > Cc: skelly@redcreek.com; dharkins@network-alchemy.com;
> > ipsec@lists.tislabs.com
> > Subject: Re: using por numbers in selectors
> >
> >
> > > I am talking about FTP ports (within TCP protocol, of course).
> > > FTP ports (typically) means port 21 and 20. But often it
> > also means 21 and
> > > some-other-dynamicaly-assigned port - what should be done
> > in this case for
> > > selectors?
> >
> > Wildcard the some-other-port bit, of course.
> >
> > > The whole issue of bringing port selectors into IPSec is a
> > big mistake to
> > > begin with (IMHO) - ports belong in the Transport Layer, not to IP
> > > layer. Bringing them into IPSec is a poor attempt to filter
> > traffic based
> > > on selectors that is better implemented by Transport Layers
> > security or
> > > firewalls.
> >
> > Do you write end-system code that extensively uses transport
> > mode IPsec at
> > all?  I'll bet you don't, because if you did you'd totally
> > understand why
> > port selectors are there in the first place.
> >
> > Do you have customers asking you if you can secure their legacy apps
> > end-to-end with IPsec?  I do.
> >
> > And yes, Solaris IPsec has port selectors and/or per-socket
> > IPsec policy.
> >
> > To answer Dan H's question about precedence, we parse in
> > order of rule-entry,
> > so it's up to the admin to decide how a question of conflict
> > gets answered.
> >
> > Dan McD. (the other Dan)
> >
References: