[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new AH spec
Dan,
<SNIP! SNIP!>
>Looks good so far. The bit about "piecemeal" might be a bit strong, but
>that's really hairsplitting.
I'm not trying to be negative, just accurate in my description of the way
in which Ah is computed over portions of the IP header, zero-filling
others, etc.
<SNIP! SNIP!>
>Mostly, the NULL authentication algorithm is used for testing of protocol
>plumbing. I don't expect any shipping product to have a null authentication
>algorithm. I do expect AH implementations that are in their nascent stages
>to have a null authentication algorithm. Interpret this data as you will
>w.r.t. how the spec should read.
I think if NULL is used only for testing, it would be better not to have it
as a cited transform/algorithm.
<SNIP! SNIP!>
>A zero SPI is useful for any number of implementation-specific aids. An
>example I can think of off the top of my head is that if my
>getassocybyendpoint() call for an outgoing datagram returns an association
>with a zero SPI, I can interpret this as any number of results (including, "I
>just kicked key management in the rear, I'll get back to you.")
As above, if a zero SPI will never appear on the wire (fiber?), I'd rather
not specify it here. What you describe is a local interface matter.
<SNIP! SNIP!>
>I know certain people who have issues about having this field NOT being
>present. I don't have a problem with this, but I suspect the people who have
>these issues will speak up.
Yes, documents have clearly diverged re the presence or absence of this
field and I'm going with the interpretation we adopted for ESP, i.e., if
the servuce is not negotiated, the field is absent.
<SNIP! SNIP!>
>BTW, ESP is one of these upper-layer protocol fields. In fact, lemme return
>to this upper-layer protocol idea in a bit.
Yep! We'll add ESP as an obvious additional example.
<SNIP! SNIP!>
I'll leave the resolution of IPv6 header element ordering to those more
knowledgable in the intricacies of that protocol.
<SNIP! SNIP!>
>This sentence is more important than is apparent at first. An implementation
>can look at the inner IP header as JUST ANOTHER UPPER LAYER. This helps
>reduce some of the special-casing for IP as the inner payload. It doesn't
>_ELIMINATE_ it, but it can reduce it.
>
>(For example, if you have A->B with the inner IP saying A->B, you can make
>stronger assertions than if the inner packet says something else.)
We can emphasize this point if you think it's important and does not
receive enough attention here.
<SNIP! SNIP!>
>As an aside, I'd strongly encourage to look at the current implementations
>out there, as well as some of the analysis literature. I suspect you've
>already done your homework on this front and will be drawing on their
>experience when you finish rewhacking the architecture document.
The implementations I have seen so far do not seem to provide the sort of
granularity that Ran's previous architecture I-D called for, and that I
called for in my talk at the last IETF WG, etc. But I am going on what
I've seen at the trade shows, not the bakeoffs, so I hope we are closer
than I fear.
<SNIP! SNIP!>
>Do you have any recommendations for when the sequence number cycles? (Kick
>key mgmt. in the pants, logging, tuning future SAs to expire sooner, etc.)
I'm tempted to say that cycling is an error, and that key managememtn
should have been kicked sooner. The architecture document can address this
in more detail, or we can say something more definite here is there is
concensus.
<SNIP! SNIP!>
>Except for perhaps DF, these FLAGS and OFFSET SHOULD be zero anyway after
>reassembly! The question of DF is perhaps why the decision was made to just
>zero out that bit too.
I think we agree on the basic premise. Note that if a security gateway
fragments a packet with AH applied already, it will be using tunnel mode,
so the DF bit covered by the inner AH is not an issue here. We will be
sending out a message iscussion DF and PMTU after Memphis.
<SNIP! SNIP!>
>IMHO, new IPv6 extensions should document their own AH properties. Keep in
>mind this is IMHO only.
I like this as an answer; it allows it to reach closure on this document.
<SNIP! SNIP!>
>Thank you! We in IPv6-land appreciate this.
You're welcome.
<SNIP! SNIP!>
>As an aside, has anyone tackled this? A lightweight digital signature
>algorithm would be perfect in a multicast environment with a small number of
>senders compared with an arbitrary number of receivers.
This is a hard problem is we look for digital signature solutions, but
maybe we'll get lucky. ECC signatures are faster and smaller, but ... Are
you suggesting solutions that are not digital signature based? I ask only
because of your comment re the number of possible senders, which would seem
not to be an issue if we use a real signature algorithm.
<SNIP! SNIP!>
>Like I mentioned before, as currently written, these I-Ds _always_ include
>the replay counter. The replay counter is set to 0 for associations that
>don't use replay.
The I-Ds cited are not ones that inlude references to counters, AH, etc.
They are raw algorithms I-Ds, which is just what we want for this style of
specification. The issue of the presence or absence of the replay counter
should be with separately, in this document.
<SNIP! SNIP!>
>Ummm, what if I live in a multithreaded world? I can theoretically get two
>packets near-concurrently with the same sequence number. If the bogus one
>arrives first, do I trash the good one just because one with the same replay
>number arrived first? Or do I not count a sequence number as "good" until
>I've authenticated? Or is this just an implementation detail? Or is this
>why it says SHOULD rather than MUST?
We can make mention earlier of the need to authentciate prior to accepting
a packet, as you observed later.
Steve
References: