-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Scott" == Scott G Kelly <skelly@redcreek.com> writes:
Scott> mcr writes:
>> >>>>> "Scott" == Scott G Kelly <skelly@redcreek.com> writes:
Scott> I'm still thinking about your proposal, and while I like the
Scott> simplicity, there is one remaining issue: neither my nor your
Scott> proposal addresses port/protocol lists. This is a difficult >
>> I keep thinking we already have that. But, we don't have port/protocol
>> in IKE yet, correct?
>>
Scott> We have them, but we only permit one port/protocol pair in the ID
Scott> payload, e.g. the ID_IPV4_ADDR payload: 1 2 3 0 1 2 3 4 5 6 7 8 9
Right. That isn't clear from a quick read of ipsec-doi (which I did
before posting to double check). I.e. if you read sections 4.6.2.1-9
then the word "port" and "protocol" do not appear. Only the diagram
in 4.6.2 mentions it, which is reasonable, but I missed it.
One thought: for protocol == ICMP, is it reasonable that the "port" field
be in fact two octets: type and code?
Do we really need port ranges? I.e. is there a situation where you want
a range, but not all ports? The only situation I can think of is something
like:
A<------>B all ports, ESP with DES
A<------>B port 23, ESP with 3DES
And that can be negotiated just fine, since the specific port address
should take priority in the SPD over the port wildcard.
Scott> The ID_AND_LIST + ID_TRANSPORT_PORT payloads may resolve this
Scott> issue, but we should think a bit more about this. It could get a
Scott> bit ugly if someone starts mixing these up with existing ID
Scott> payloads that contain ports/protocols, and I'm not sure (without
Scott> giving it a lot more thought) that we won't break something.
Agreed. Maybe the other types are not valid unless you set the
protocol/port to wildcard. Do we have transports that require more than two
bytes for "port"??? Hmm. YES! ESP/AH!
Scott> As an aside, we're ignoring the overloaded-id-payload arguments
Scott> here...
Please elucidate, I don't follow.
:!mcr!: | Solidum Systems Corporation, http://www.solidum.com
Michael Richardson |For a better connected world,where data flows faster<tm>
Personal: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. PGP key available.
Corporate: <A HREF="mailto:mcr@solidum.com">mcr@solidum.com</A>.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQB1AwUBNgf7a9iXVu0RiA21AQH0nwL+L3ETP0g7rE2zOxj/J6YbRSxG7XyY79S5
hrVpHnRhPhIW47LAQCAxivSGlJmoWU9BL8YlJhtBtTyiN961a1MCQQNk9n4yjOLd
gbyVq+LSYlDIuKNSGz0o2gfG/WXwqVgV
=8CxA
-----END PGP SIGNATURE-----