Yoav Nir <y...@checkpoint.com> wrote:
>> I also wonder if having four Shortcut Notify types might just be simpler
to
>> implement, rather than having another layer of type codes.
>> I'm also not clear why a Notify: it seems like it ought to be an entirely
>> normal payload type, cousin to Proposal.
>> One might even argue that this is a new kind of *Proposal*, the "shortcut
>> proposal". My goal here is to reuse as much as the current decoding and
>> validation code as possible.
> Yaron proposed that we replace at least the three types of shortcut
> into one, and add an ID payload (IDs with s for "shortcut"?) that
> describes the peer and might contain an IP address or DNS name. Either
> way, it's kind of weird to have regular payloads inside a Notify
> payload, or even a new type of payload. Maybe the best path would be to
> have a new exchange type, that contains payloads (as messages tend to
> do). Of course in that case we can't omit the generic header.
I am in favour of a new exchange type then.
>> It seems that port numbers belong in the Shortcut Types.
> Sorry, I don't get that.
I was assuming that we would need port numbers in order to support spokes
behind NAT. Not all NATs will support that, but some will.
> All of them omit the generic header.
>> Gee, I'd sure rather we weren't encouraging more PSK use.
> PSKs are great! The only problem with using PSKs is that people
> configure short, memorable ones. In this specification, the suggester
> generates really, really secure PSKs with $BIG_NUMBER bits generated by
> a $YOUR_FAVORITE_GOVERNMENT_AGENCY-approved PRNG. Isn't this better
> than trusting some CA?
I guess....
>> I'm finding the IDx payloads interesting: it is interesting that the
identity
>> is being managed here. That sure gets around a whole host of issues with
>> letting the gateways use their own identities, which might be tied up
with
>> certificates and other stuff. I think that some recommendation should
made
>> (and some MUST implement) about ID types here.
> Since some implementations are going to use certificates for shortcuts,
> I guess we should have at least the ID_DER_ASN1_DN type, maybe also the
> ID_FQDN and ID_IPvX_ADDR address. ID_KEY_ID is good for PSK, but then
> maybe we want to use ID_RFC822_ADDR for users. Aaargh.
Can the IDx be omitted?
>> Re: the situation in A.3. If officeGW realizes that peer1 and peer2 are
in
>> fact on the same subnet, etc. is there any way for it to tell them to
create
>> a "bypass" between them?
> Currently not. But is that a good idea? They might be on the same
> subnet (think IETF network), but that network may not be trusted (hey,
> all my company's competitors are on this network).
The spoke gets to decline if it thinks it is in an unsafe place.
> We do plan to have something like a bypass shortcut in the next
> iteration, but that is for cases where the center gateway forwards a
> particular slice of traffic to the Internet, so the spoke gateway might
> as well forward to the Internet all by itself. There should be some
> consideration given to NATs (like if the spoke was protecting RFC-1918
> addresses, and the center gateway was doing the NAT before sending them
> to the Internet)
good.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
pgpeMCo0mvUNO.pgp
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
