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

Re: multiple payloads via "ID_LIST"

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?
> 
We have them, but we only permit one port/protocol pair in the ID
payload, e.g. the ID_IPV4_ADDR payload:
                       1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !   RESERVED    !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!   ID Type     !  Protocol     |             Port              !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                 IP  Address                                   !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

> Perhaps we need to have two types of ID_LIST: AND and OR.
> Add to that ID_IPV4_PROTOCOL, ID_IPV6_PROTOCOL, ID_TRANSPORT_PORT.
> 
> Thus, to negotiate a secure Telnet session, one says gives one end as
> being:
> src: ID_AND_LIST:
>      [ID_IPV4_ADDR: client, ID_IPV4_PROTOCOL: TCP,
>      ID_TRANSPORT_PORT: 65418]
> 
>   dst: ID_AND_LIST:
>         [ID_IPV4_ADDR: server, ID_IPV4_PROTOCOL: TCP, 
>         ID_TRANSPORT_PORT: 23]
> 
> Scott> is almost certain to provoke strong resistance), or adding new
> Scott> ones. Have you considered this problem?
> 
> I think we have to add new ones.
> 
> { One alternative is a declarative packet description language (an 
> internet draft describing ours will be published very soon):
>         "ip4TcpConn(client, server, 65418, 23)"
> }

The ID_AND_LIST + ID_TRANSPORT_PORT payloads may resolve this issue, but
we should think a bit more about this. It could get a bit ugly if
someone starts mixing these up with existing ID payloads that contain
ports/protocols, and I'm not sure (without giving it a lot more thought)
that we won't break something.

As an aside, we're ignoring the overloaded-id-payload arguments here...
Follow-Ups: