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

Re: ESP and AH used in tunnel mode by a Security Gateway


Steve,

Stephen Kent <kent@bbn.com> writes:

[AH discussion snipped -- I need to think some more before responding]

> I haven't examined it carefully, but I might not have big problem with
> viewing the AH-ESP bundle (with just one inner IP header) as being a valid
> tunnel, since they were noth applied at the same time and will be
> decapsulated together.  The critical issue is how fragmentation is handled
> and what headers are checked upon decapsulation.  (We stopped using the
> term "transform" a long time ago, so I don't know how to reconcile some of
> what you said, but ...)  Yes, we've tried to move toward an IP-in-IP tunnel
> notion over time. Ran used to argue that there was a fundamental difference
> between what we were doing and IP-in-IPf tunneling, but I've not been able
> to really understand what the differences were, so they have tended to blur
> over time.

I guess this must have been a result of private discussions (or
inadequately documented IETF meetings) because the first reference I
can find to the DF bit is Ran responding to me (11. Feb 97):

Ran wrote (M-ID = <Chameleon.855633160.rja@c8-a.snvl1.sfba.home.com>):

>   It is worth noting that none of the IPsec RFCs cite any of the IP-in-IP
> RFCs.  This is not an accident.  With IPsec, one is not performing IP-in-IP.
> Rather, one is performing IP-in-AH or IP-in-ESP.  The IP-in-IP RFCs don't
> include IPsec within their scope.

>   It was quite intentional that this was done.  It is equally intentional
> that the IPsec RFCs haven't been citing the IP-in-IP RFCs.

>   In effect, ESP tunnel mode uses the outer IP as a link-layer.  Copying
> DF bit is not prohibited for IPsec tunneling, but neither is it required
> for IPsec tunneling.

Perhaps I'm clouded by my own implementation experience, but I really
don't see a fundamental difference between our objective and that of
IP-in-IP.  With time, our methods for achieving this objective have
diverged and the current docs don't mesh well.  However, I don't see
why we couldn't currently merge them and simplify the lives of future
implementors.

The one major difference I have seen has been in the handling of the
DF bit.  I guess I missed somthing in my archive search, but I don't
really see any strong rationale for handling it different from
IP-in-IP.  If (as a SG) I receive a packet from a host with the DF bit
set, it is my job to interpret this as a willingness for that host to
reduce its segment size in order to avoid the overhead of the
fragmented packet.  I am misrepresenting that machine (and further
conjesting the network) if I don't include it in the outer header and
perform PMTU discovery for the tunnel (which looks like a single-hop
link to that host).

The only reason I can see to change this behavior would be to provide
an extra bit of security (if I never set the DF bit on the outer IP
header, there is slightly less information that can be learned
concerning the hosts in my network).  Should this be a valid concern?

Is there any other fundamental difference I'm missing?

Back to quoting Steve:

> >Hmm...  Is it not best to describe the current running systems?  If we
> >were to describe the way that AH+ESP is negotiated between Security
> >Gateways, it would pretty much require having a pointer to somewhere
> >in the Arch document.
> 
> The current crop of running suystems embody a variety of characteristics,
> not all of which are consistent with one another, or with the specs.  Also,
> none of the ones I;ve seen is completely compliant with the specs, despite
> receiving ICSA certification!  So, no, I don't want to change the spec to
> match what the current crop is doing, if that deviates from what this WG
> has labored long and hard to agree upon. The last time we adopted this
> rationale we deleted the ability for ESP to have null encryption because
> the "then current" crop of implementations didn't support it; this feature
> was rediscovered as important a number of months later, and added back at
> that time.   Let's not repeat history.

Your fear is well stated.  However, it seems that this attitude might
well steer us towards making the opposite mistake.  This is something
that several of us would like to do that is currently ommited from the
documents.  Not documenting it means that interoperability will be
entirely goverened by chance and interop attendance (and not by a
correct implementation of the specs).

The only result of our past labors is to decide that AH+ESP should not
be a requirement for Security Gateways.  Some of us have chosen to
implement it because it seems useful.  Now, we'd like to agree upon a
way to negotiate this using the IPsec DOI (which is merely a matter of
choosing one of several possible good solutions).  The DOI document is
an appropriate place to put this OPTIONAL configuration mode.
However, it is not an appropriate place to describe the optional
encapsulation mode that it refers to.

All I'm asking is to document this optional encapsulation mode in the
Architecture document.  It is not required functionality and should be
documented that way (probably using a "MAY").  However, it is an
option that some of us would like to support and it should be
documented.


ben
References: