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

Re: On the Use of SCTP with IPsec




In message <005201c09f64$9c008680$8a1b6e0a@arenanet.fi>, "Jari Arkko" writes:
 >
 >I'm not sure I understand why PKIX needs to be involved. Weren't
 >you referring to my comment about the use of recursive identities
 >also in the context of other things, such as better specification of
 >how ICMP is treated? Even today we have ports and protocols in
 >the IDs, and we don't require them to appear in certs in any way...
 >if an implementation checks the validity of the phase 2 selectors
 >against the phase 1 identity, that check most likely omits the port/protocol
 >information, right?

Never mind, I think misunderstood you original comment. Anyway, you're correct
in the above.

 >But this reminds me of an issue that wasn't clear to me. In your
 >draft section 3.b you talk about IKE validating the phase 2
 >selectors, and getting sufficient info during phase 1 in order
 >to do this. But have you defined exactly how to do the "validation"?
 >
 >- Do we always need to do validation in the first place? If multiple
 >  phase 2 selectors are proposed, couldn't it still be the case that the
 >  phase 1 identity is a trusted fqdn, for instance? 

Correct; note however that 3b discusses just the simple case of two machines
that want to communicate using IPsec without any prior arrangements. In that
case, the certificates themselves need to encode enough information to validate
the Phase 2 selectors ("yes, you're really talking to x.y.z.w").

For anything more complicated, you need to use a more elaborate policy
mechanism. The case of a trusted phase 1 fqdn identity falls under this
category.

 >- Is the validation an equality check on the IP addresses? Are only
 >  IP addresses allowed then? I suppose I can use less addresses in
 >  phase 2 than in phase 1, but not more?

Again, for the *simple* case of two hosts doing IPsec without prior
arrangements (what FreeSWAN calls "opportunistic IPsec"), the check would
be IP-address based -- less addresses than are encoded in the certs or
further restrictions on the Phase 2 selectors (e.g., only TCP) would be
acceptable.

 >- Suppose in phase 1, I present the certificate with AltName="1.1.1.1, 1.1.1.2
 >"
 >  and the identity "1.1.1.1 OR 1.1.1.2". Can I present a phase 2 selector
 >  proposal of "1.1.1.0/31"?

Depends on how smart the implementation is. I would imagine noone would
gracefully handle this.

 >- In the same style, can I use IPSEC_ID_IPV4_SUBNET for phase 1
 >  and individual addresses from this network in phase 2? How are the
 >  network/broadcast addresses treated in this case?

I don't think SUBNET and RANGE are valid Phase 1 identities currently; we don't
propose to change this.

 >- Must we really require the addresses to be in the cert, too?
 >  What if somebody comes up with a multihomed SCTP node
 >  that uses dynamic IP addresses? This might happen easily
 >  in an IPv6 setting with a node that has multiple network cards,
 >  for instance.

Let me bounce the question back to you, by changing SCTP with TCP. The
answers to both questions are the same. Again, what we're discussing in
the draft deals with relatively simple extensions to deal with the
multiplicity of endpoints of an SCTP node.
-Angelos





References: