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

Re: Ikev2 Traffic Selector payload



I too agree with Valery Smyslov's suggestion: Have the initiator specify
the specifics of the packet that caused it to want to create
the child-SA. However, there are a bunch of ways this
could be done. Any opinions?

For example, we could say that the first selector of TSi MAY be the
specifics of the source of
the packet that's causing the initiator to create the child-SA,
and the first selector of TSr MAY be the specifics of the destination
of the packet.

The responder will choose the largest ranges of addresses and ports
it can accomodate.

So far, no changes to the spec.

But here's the change that incorporates Valery's suggestion, I think:

   If the responder has multiple ranges, and can't choose, then he
   MUST choose the largest set that encompasses the first TSi and first TSr.
   
Also, if the initiator didn't put the specifics of the first packet into
the first TSi and first TSr, then should we:
  a) generalize the "SINGLE-PAIR-REQUIRED" to instead mean "you have to
     be more specific, or
  b) (I think I prefer this one), have a new error type for "more specific
     ranges required". After receiving such an error, the initiator can
     guarantee success next time by putting in the specifics of the
     packet into the first TSi and first TSr.
     
By the way, it's 12 bytes for
each one, so it's 24 bytes of overhead to include
this information.

I'm confused about what a firewall is supposed to do if it's just
configured that when it comes up it creates a set of SAs, and there
is no specific packet that is triggering the SA creation. I suppose
that's just a misconfiguration between the policies of the two sides?

Radia