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

Re: IPSEC AH -- document

Norm responding to Steve:

 > > 	The reason for the additional text is exactly what it says, i.e.,
 > > because of the need to deal with fragments transmitted by the host.
 > > Perhaps the wording was too strong, and should merely be a warning that
 > > these implementations must be aware of the requirement to apply AH (and
 > > ESP) only to complete datagrams.   I note that fragments created by the
 > > host might exist via two different interfaces in a multi-homed host, so a
                ^^^^^
                exit?

 > > BITW device or very low level BITS code might not be able to do reassembly,
 > > IPsec, and then refragmnent, in that instance.   Such implementations would
 > > have a similar problems for incoming fragements that arrive on separate
 > > interfaces and would be reassembled in the native IP implementation.  So,
 > 
 > Seems to me that all incoming fragments have the same IP destination address,
 > and thus must arrive on the same interface. Am I missing something?

Norm, you bring up a valid issue for inbound.  I think I agree that all
the packet fragments, even though they may be routed differently, will
probably arrive on the same interface/wire.  Its hard to envision how
they could not do so with standard routing but don't overlook
static/explicit routes to get the fragments in via a different
interface.  However, depending upon whether you have the "weak" or
"strong" IP end-system model, as mentioned in RFC 1122, it is permitted
for a host to accept packet fragments on a different interface than the
one addressed and then reassemble it with fragments that came in on the
"correct" interface.  A BITS (bump-in-the-stack) implementation that
sat between IP and *all* drivers/interfaces could/should be designed to
handle this.  A BITW (bump-in-the-wire) implementation or an
interface-card implementation (that didn't have "special hooks" into
the IP system) could have more trouble to, as Steve is pointing out.

Steve, assuming you meant "exit" above as I noted then I agree.  A
multi-home host could "spray" fragments of a single packet out different
interfaces.  I can think of multiple scenarios where a native IP stack
may do this.  However, in all the scenarios I can think of, a BITS
implementation that sat between IP and all drivers/interfaces could
easily resolve the issues, do you agree?  Even a BITW interface-card
solution could, with some "special hooks" back into the native IP code
(though that would probably be "ugly").  A BITW implementation *could*
have problems or may require special implementation support or operational
restrictions for these worst-case, multi-home scenarios.  Also, keep in
mind that relatively few hosts (on a world-wide percentage basis) are
multi-homed and so wouldn't have any problems at all with almost any
reasonably-sane BITS or BITW implementation since there is only one
path for packets.

 > 
 > > those worst case scenarios motivated my recommendation.  Still,  I'm happy
 > > to change the wording to merely refelct the requirement that special care
 > > must be taken in these implementations to ensure the ability to properly
 > > perform AH and ESP, on both outbound and inbound traffic.  Would that be OK?

Steve, this would be OK.  I'm fine on also specifically pointing out that
fragmentation coupled with multi-homing may pose some extra challenges
to BITS and BITW implementations, if you'd like.  That appears to be the
main point here.

I'm also fine on removing all BITS/BITW references from everywhere but
the Security Architecture and just have AH & ESP address the main
IP/IPSEC integrated stack behavior model.  Just let BITS/BITW implementers
figure out how to interoperate with these in all IPSEC Transport/Tunnel
modes and desired topologies/configurations.  Your (and the group's) call.
I understand your motivation to try and offer some guidance to BITS/BITW
folks so I'm still OK with the previous paragraphs.

I just want to avoid making any statements/judgements on what an
implementation may be able to solve/do to conform with IPSEC.  Your
current wording about "not recommended...be unable to process these
packets according to this specification" (given that IPSEC is something
folks will be reading carefully since security is important and yet not
with full understanding of a given implementation) is more than
"strongly worded".  Its equivalent to the IETF saying "don't do
this" or "there be security holes here".


Thanks.
                        
                         
   -- Marc --
Follow-Ups: