[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SOI QUESTION: 5.3-6.5
> 5.3 SPD entries
>
> 5.3.A) Is it important in SOI to allow the the responder to
> accept a subset
> of the proposed SA, or should it be an all or nothing acceptance?
That's a tough question. I'm tempted to say no instinctively because IKE
should be doing policy agreement and not policy discovery. I think we have
to look at the scenarios for this one. Why would you want to restrict an SA
to a subset of the offered selectors? Is it because the initiator doesn't
know the identity-IP binding? Or to enforce firewall rules? Or to set up
QoS-specific SAs? Any one of these is a questionable motivation.
I don't understand the rationale behind SINGLE-PAIR-REQUIRED from the IKEv2
draft. What's the point of this? (And why is it SINGLE-[IP-]PAIR-REQUIRED
and not SINGLE-PORT-PAIR-REQUIRED?) When we discussed this basic issue on
the list in August '01 the general consensus was that it is better to send
all traffic on one SA in order to thwart traffic analysis. The only
advantage to having separate SAs is to thwart attacks such as the one
discovered by Scott Fluhrer. Now that we've discovered such an attack (and
learned how to prevent it), is there any further use for this?
> 5.3.B) Should the SOI offer multiple selectors with specific ports and
> addresses, or a single selector with a range of ports and range of
> addresses? (complicated boolean complexity!)
I think we need to support lists of ranges of IPs, perhaps with the
provision that they must be ordered sequentially. Lists of ranges is the
most compact and unambiguous selector type. When we add the ports (a list of
ranges of ports, I guess), I assume that the ports will apply to every IP in
the list. I can't really think of any situations in which I would want to
use port selectors with IP ranges, but apparently this is a requirement for
IP storage (although I am fuzzy on the rationale for this).
> 6.1 Message encoding
>
> 6.1.A) Should SOI worry about aligning parts of messages on 2 and 4
> byte boundaries?
I guess that would be okay. We have seen some issues with this, although
it's nothing that can't be avoided by careful programming. I think it would
eat up a lot of extra space on the wire, though.
> 6.1.B) Should SOI tag its protocol with version numbers?
Yes. How can this not be obvious?
> 6.1.C) Should SOI format be roughly the same as IKEv1? (See
> discussion in section 6.4, re: code preserving)
It would be nice. I see no real advantage to one encoding scheme over
another, so why change?
> 6.2 Port number
>
> 6.2.A) Should SOI use the same port as IKEv1? (See discussion in
> soi-features-01 the tradeoffs in this question).
I have no strong opinion on this. We're already going to be supporting
multiple ports for NAT traversal anyway.
> 6.3 Future versions of the protocols
>
> 6.3.A) Should SOI have a mechanism for demanding/requesting that a
> peer use a particular version of IKE/SOI to allow upgrading to new
> versions?
Yes.
> 6.4 Code-preservingness
>
> 6.4.A) Is it important that SOI allow some amounts of an IKEv1
> implementation be reusable when creating an SOI implementation?
It has already become obvious to me that SOI is going to require quite a bit
of rewriting, however when I have analyzed the changes I see that a lot of
code is still going to be reusable. So yes. The more different the protocol
is, the more changes will be required.
> 6.5 Extensibility of the protocols
>
> 6.5.A) Should SOI have mechanisms for allowing extensions to the SOI
> protocol?
Unquestionably yes. This is an issue that I'm completely adamant about.
Aside from just allowing experimental/proprietary features, the vendor id
gives a smooth upgrade mechanism. Early on in the deployment of IKEv1, we
had an issue where the spec changed, leaving us with deployed boxes that
were incompatible with the new draft. This was before the invention of the
vendor id and we needed a transition mechansim, so we were forced to come up
with a fairly kludgy solution. A vendor id would have allowed us to detect
incompatible versions in the field and adjust our behaviour accordingly.
> 6.5.B) Should SOI need a way to mark new extensions as critical?
> (i.e. If you don't understand a critical extension you must fail the
> entire negotiation)
Might as well. The argument that vendors will purposely set the critical bit
in order to hinder interoperability is just silly.
Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.