[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Phase 2 IDs
What are the allowed ID type in Phase 2. I take that all are allowed
in phase 1, but phase 2 don't look like can accept FQDN types for instance.
Can anyone enumerate all the supported type in phase 2. It'd be a great
help. I'm pretty sure that types ID_IPV4_ADDR, ID_IPV4_ADDR_SUBNET,
ID_IPV6_ADDR, ID_IPV6_ADDR_SUBNET are accepted, but I'm not sure about the
rest.
Here's the list of all the type so that no one has to check it from
the RFC:
ID_IPV4_ADDR 1
ID_FQDN 2
ID_USER_FQDN 3
ID_IPV4_ADDR_SUBNET 4
ID_IPV6_ADDR 5
ID_IPV6_ADDR_SUBNET 6
ID_IPV4_ADDR_RANGE 7
ID_IPV6_ADDR_RANGE 8
ID_DER_ASN1_DN 9
ID_DER_ASN1_GN 10
ID_KEY_ID 11
Thanks!
Toni
-----Original Message-----
From: EXT Chris Trobridge [mailto:CTrobridge@baltimore.com]
Sent: 16. June 2000 10:08
To: Radia Perlman; ipsec@lists.tislabs.com
Subject: RE: Deprecation of AH header from the IPSEC tool kit
> Ran said:
>
> >> A counter-example is the Source Routing
> header, which can
> >> be authenticated hop-by-hop with AH ...
>
> How do you authenticate something hop-by-hop when the key is only
> known end-to-end? Are you maybe assuming hop-by-hop IPSec
> tunnels between the
> routers listed in the source route header?
>
> Radia
>
Intermediate hops can't use the end to end AH to verify the datagram.
Of course the end point can check that the source route hasn't been modified
in transit. I'm not sure what attacks this prevents beyond denial of
service though?
Chris
Follow-Ups: