[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AH (without ESP) on a secure gateway
-----BEGIN PGP SIGNED MESSAGE-----
Okay, I had to draw a diagram to parse what you said, which means
that I might not have understood it:
[I'll pick actual SPI's here]
Scenario:
A.1 <-----A--------------------B-----------> B.1
Kent> - firewalls A and B use AH for protection between them
This must be in tunnel mode. There is no other option. While they
might have reasons to authentication packets directly in a network
address translation case (application layer firewalls for instance,
remember Bob Moskovitz's challenge) that is involved layers above IP.
Kent> - all traffic from A is AH protected using a single SA
(i) A--------SPI=257---->B
Kent> - host A.1 (behind firewall A) establishes an SA to B.1 (behind
Kent> firewall B) and this SA is also an AH SA
A B
(ii) A.1 ---------------SPI=x------------------> B.1
Kent> - host B.1 chooses the same SPI for the traffic from A.1 to B.1 that
Kent> firewall B chose for traffic from A to B
Let x=257.
So the issue is what does firewall B do when it receives a packet
for with SPI=257. Here are some packets (e.g. DNS requests in UDP)
1. [IP src=A.1, dst=B.1][AH SPI=257 [UDP [DNS]]]
2. [IP src=A, dst=B][AH SPI=257 [IP src=A.1, dst=B.1] [UDP [DNS]]]
3. [IP src=A, dst=B][AH SPI=257 [IP src=A.1, dst=B.1] [AH SPI=257 UDP [DNS]]]
4. [IP src=A.1, dst=B.1]
[AH SPI=257 [AH SPI=257 UDP [DNS]]]
Several observations:
a. SPI's are index by destination address. Firewall B can
notice that case #1 is not addressed to it. Firewalls with
transparency concepts (BlackHole, Eagle 4.0, BorderWare, ???)
will have to be aware of these things.
b. Case #4 was decided to be illegal some months ago.
c. Why would firewall B let packets of type #1 through?
Who is A.1? How did B.1 authorize such a packet? This is the
question that I addressed during my minutes at the montreal IETF.
Packet types #2 and #3 represent tunnel mode with and without
end-to-end authentication.
:!mcr!: | Network security consulting and
Michael Richardson | contract programming
WWW: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. PGP key available.
p.s: no I won't be in San Jose. I no longer have a corporate sponsor
to pay my bills.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2i
iQBVAwUBMqOszdTTll4efmtZAQES7QIAtRaKrKDxTZQWF44m1A3l0shWH9G7HcXk
byNCZlvyOndSRb/Po+pIpWKz7z/x5zNYyjc7uUDHG5kKxNsOvDs61g==
=IGlv
-----END PGP SIGNATURE-----
Follow-Ups:
References: