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

RE: tunnle mode SAs...



I thought the problem was to do with inbound policy processing.

If a packet is fragmented before encryption then you can't tell the
protocol/ports/whatever of the later fragments when they're decoded (I
suppose this is a problem outbound too).

Transport mode is end-to-end, so why would intermediates get involved?

I think fragmenting the ciphertext is ok, in principle, but fragmenting
plaintext datagrams prevents gateways from processing policy.

Chris

> -----Original Message-----
> From: Stephen Kent [mailto:kent@bbn.com]
> Sent: 25 April 2001 14:29
> To: Jain, Gautam
> Cc: 'ipsec@lists.tislabs.com'
> Subject: Re: tunnle mode SAs...
> 
> 
> At 5:11 PM +0000 4/24/01, Jain, Gautam wrote:
> >With reference to section 4.1 in RFC 2401 I have a question on the
> >following statement.
> >
> >The requirement for any (transit traffic) SA involving a
> >security gateway to be a tunnel SA arises due to the need to avoid
> >potential problems with regard to fragmentation and reassembly of
> >IPsec packets, and in circumstances where multiple paths (e.g., via
> >different security gateways) exist to the same destination behind the
> >security gateways.
> >
> >How does a tunnel mode SA avoid the fragmentation problem and why
> >is a transport mode SA a problem if there exist multiple paths to the
> >same destination behind the security gateways ?
> 
> In tunnel mode packets are addressed to a single target SG, thus 
> ensuring that all fragments arrive at one point, where they can be 
> reassembled. In transport mode, the address of the ultimate target, 
> not the SG, would allow traffic, including fragments, on one SA to be 
> routed to different SGs, and this would preclude reassembly at an 
> intermediate SG.
> 
> Steve
> 
> 
> 
> 
> This footnote confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> 


-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.