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

Re: New draft -- IPSEC AH



In article <3.0.1.32.19970531092527.009531bc@ranier.altavista-software.com>,
Matt Thomas  <matt.thomas@altavista-software.com> wrote:
> I think that we need to exclude (e.g. treat as zero) the flow-label and
> priority/reserved bits as well, especially if they are allowed to be
> changed inflight.

How do QOS types feel about this?  Are they relying on AH to authenticate
packets and priority/flow fields for QOS control?

> [Since the version field is constant I'd exclude that
> as well so the first 32 bits of the IPv6 header are treated as zeroes.]

Sounds dangerous to me.  What protection is there against attacks that
try to transmute AH'ed IPv4 datagrams into AH'ed IPv6 datagrams with
different semantic meaning?  (And even if there is some protection I'm
overlooking, I think it's good to include the version field-- robustness.)

Personally, I think the version field should be included.

Moreover, I think the the IPv4 offset field should be included, too.
In the latest draft, the MAC does not protect the offset field.  Yes,
I know receivers MUST discard AH packets with offset > 0.  But this
is a robustness / engineering concern.  (There's no additional cost in
MACing the offset + version, too -- once you've decided to incur the
cost of MACing some header fields, you might as well MAC offset + version
too.)