[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ESP revisions straw poll
Angelos,
> You can do tunneling (IP in IP), with the inner packet being AH
> protected, ie: [IP][IP][AH][whatever]
Yes, that is one way to work around the problem. Cost: 20 (40)
unnecessary bytes per IPv4 (IPv6) packet sent over the lifetime of the
protocol. When viewed from the perspective of a security gateway,
[IP][IP][AH][IP][whatever], just makes things more likely to run into
path MTU / fragmentation problems.
> It has also been the IETF "policy" that decisions are made by running
> code and rough consensus.
Speaking of running code, does anyone have operational experience on
how well Path MTU discovery works? It has been standardized for a
long time.
Re: encryptionless ESP
> I believe the matter has been discussed for a while and the WG has
> indeed decided against e-ESP.
Yes, it has been discussed for a long while. There was a request for
a poll and I responded with what I think is the best solution and
my rational for thinking so.
> But more importantly, IPsec is a network layer protocol. It gives some
> assurances to the application. If the application cannot live with
> those, it should certainly use some higher layer security protocol
> (such as TLS). Trying to put in IPsec all the functionality of all
> protocol layers is a mistake.
Good points. But providing functionality needed by several layer N
protocols at a lower layer has merit.
> I'll remind you that IP addresses are supposed to be used as part of a
> security identifier; an address along with an SPI indicates the SA to
> use.
Since you raised the issue, do you know the rational for that
decision? I can see how it might make construction of third party
wire tapping devices a little easier. However, as an implementor, I
would not implement it that way. I would make the SPI space within a
box be unique, not have several spaces, one per address -- IPv4, IPv6
link local, IPv6 global, (dare I say multicast?), per interface, ...
Why go through all the extra work? Bigger tables, bigger hash keys
... From the outside, things work. If the box receives a packet not
addressed to it, it gets dropped before any SPI lookup. If it is
addressed to the box, the purported SPI either works or it doesn't.
If it works, whoever shared the key, so the packet would be accepted;
if it didn't work, it would set off those audit or not alarms and be
dropped.
> Additionally, i don't see how dynamic IP will be hampered by IPsec in
> this respect, assuming a well thought out certificate scheme is in
> place; specifically, certificates for mobile agents should not include
> any IP addresses (this is a necessary but probably not sufficient
> condition).
>From what I've had a chance to read, that may be a big assumption.
Thinking ahead a few years, what fraction of hosts and networks will
be mobile (at the IP level) or be subject to renumbering, possibly due
to switching providers? Hopefully, someone is working out all the
nasty little details.
Re: IV field padding:
> I'm puzzled by this. Why wouldn't the standard padding at the end of
> the ESP payload be enough to handle alignment problems ?
No. Maybe a picture would help.
64-bit boundaries (not to scale)
| | | | | | | | |
+-------+-------+-------+---- +-------+-------+------------+-------+
|IP6 Hdr|Rtg Hdr|ESP Hdr| IV |IP6 Hdr|Rtg Hdr|User Payload|ESP Pad|
+-------+-------+-------+---- +-------+-------+------------+-------+
When the decapsulating system gets this packet, it will "strip off"
the headers before the (IV and) inner IPv6 header, and then have to
process that header and possibly others beyond it (inner Rtg Hdr in
this example). It is expected that the outer IPv6 base header and
extension headers are aligned so those systems that demand data
alignment can process the packet. But this system has to also process
the inner headers. Maybe the inner routing header needs to be
advanced, and IPv6 addresses shuffled around. If the IV field is not
a multiple of 64 bits, it breaks the alignment between the outer and
inner headers, then the vendor is stuck realigning the the packet,
which is a good way to reduce performance. Some have argued that the
encrypted portion (IV through ESP Pad) would have to be copied anyway
so it doesn't really matter. In some cases that argument works. But
requiring the IV field to be a multiple of 64 bits would make it work
in all cases, allowing the vendors to simplify their implementations.
Given current technology, it only costs a few words, and would nail
things down unambiguously. I think it is a reasonable requirement.
If others feel otherwise, we should know so that the working group
documents can warn vendors not to make "assumptions".
Thanks for your feedback,
Charlie