Subject: [IPsec] comments on draft-sathyanarayan-ipsecme-advpn-00

From: Michael Richardson <[email-masked]>
Date: Mon, 29 Jul 2013 15:42:46 -0400

This is a really minor comment: you reserve 3-39999 as unassigned
and 40K+ as private use.  Why not make that boundary 49152, nice binary
multiple.

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.

It seems that port numbers belong in the Shortcut Types.

I think that an IPv4 shortcut is one that traverse IPv4, and it could have
anything inside it. (IPv4, IPv6, maybe even transport mode SAs)
I'd rather see IDi/TSi embedded in this using the normal payload structure of
IKEv2.

Do the IDi/r and TSi/r payloads include their normal 4-byte header?
The IDi description says no generic header.... the TSi description should
be moved up to the TSi description.

Gee, I'd sure rather we weren't encouraging more PSK use.

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.

I like Appendix A.2. I'm glad you took the suggestion of having the shortcut
be learned incrementally.

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?

--
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Yoav Nir <[email-masked]>
Date: Tue, 30 Jul 2013 06:56:43 +0000

Hi MCR

> and 40K+ as private use.  Why not make that boundary 49152, nice binary

Yes, that's more conventional. But why do we prefer the convenience of machines (who don't really care one way or the other) to the convenience of people, who work in decimal?

> 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.

> It seems that port numbers belong in the Shortcut Types.

Sorry, I don't get that.

> be moved up to the TSi description.

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? 

> (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.

> fact on the same subnet, etc. is there any way for it to tell them to create

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).

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)

Yoav

---

From: Michael Richardson <[email-masked]>
Date: Tue, 30 Jul 2013 04:52:11 -0400

> 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.

    > 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.

    > 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....

    > 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?

    > 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  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [