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

Re: Why can't ?



At 01:19 PM 3/18/98 -0500, Mingtai_Chang@ne.3com.com wrote:
>
>
>
>
>
>
>
>
>
>
>
>>But you have not answered for some 'Questions' please..
>>At 11:34 AM 3/16/98 -0500, you wrote:
>>
>>
>>>With respect to the draft draft-ietf-ipsec-arch-sec-03.txt
>>>Case 3.  This case combines cases 1 and 2, adding end-to-end security
>>>       between the sending and receiving hosts.  It imposes no new
>>>        requirements on the hosts or security gateways, other than a
>>>        requirement for a security gateway to be configurable to pass
>>>        IPsec traffic (including ISAKMP traffic) for hosts behind it.
>>>
>>>    =============================================================
>>>   |                                                             |
>>>   |                  =======================                    |
>>>   |                 |                       |                   |
>>> --|-----------------|---                  --|-------------------|--
>>>|  |                 |   |                |  |                   |  |
>>>| H1* -- (Local --- SG1* |-- (Internet) --| SG2* --- (Local --- H2* |
>>>|        Intranet)       |                |          Intranet)      |
>>> ------------------------                  -------------------------
>>>   admin. boundary                            admin. boundary
>>>
>>>Here consider that the host H1 sends out fragments or the incoming
>packets
>>>to the SG1 are fragmented then
>>>* Whether such situation arises that the incoming packets to a security
>>>gateway are fragmented ?.
>>Obviously it would.
>>
>>>all the packets (eventhough they are not destined for it, because
>>>reassembly occurs only at the destination) and apply tunnel mode i.e do
>>>IPsec processing on the reassembled packet and sends it out with or with
>>>out fragmentation as needed.
>srinu>> You have not answered whether the SG1 reassembles the fragmented
>     >>packets from H1 and apply the IPsec OR discards them.
>     >>(please answer me cnsidering the draft stds).
>
>
>
>I went back to draft-ietf-ipsec-arch-sec-04.txt, and this is what I gather
>from section 4.4.2:
>
>1. On receiving a fragment from H1, SG1 goes through its SPD, looking for a
>match.
>
>2. If the fragment matches no SPD entries, discard it. (More specifically,
>it "mismatches" some part of the selectors in every SPD entry which do not
>involve OPAQUE fields. In other words, it is ruled out umambiguously.)
>
>3. If the fragment matches a SPD which does not involve Source and
>Destination Ports, SG1 accepts it and applies IPSec. (This implies SG2 must
>re-assemble. It also implies all associated fragments must go through SG2
>before reaching H2.)
>

Srinu>> When the source and destination ports are not involved, I feel you
are right, that we can apply apply IPsec on fragments. 
*But why we need re-assemble at SG1 ? When SG1 can nicely apply IPsec
processing directly on fragments. So that at the receiver end when them
IPsec processing is done we will get the actual fragment then we can
re-assemble. Am I right ?

>4. If the fragment matches a SPD which involves Source and Destination
>Ports, discard the fragment and send out ICMP PMTU.
>
>
>
>It is not clear from the draft if SG1 would handle the "Transport Layer
>Protocol" selector fields the same way as the Ports or not.  To be
>consistent, it should.

Thank u

Srinu


References: